Suggest to the developer

The button on every page: what to write, screenshots, who reads it, the Portal Owner's list.

While YouEDC grows, the best ideas come from the people who work in it. The small light bulb button in the top bar of every page — Suggest to the developer — opens a short form: write an idea, a problem, an inconvenience or a question and, if you like, add a screenshot. Then the suggestion goes through the tracker: it is reviewed, decided on, the author sees every step and in the end checks whether what was done works.

The form opens on the right over the page: whatever you typed on the page stays.

How to send a suggestion

1. Press the light bulb in the top bar, left of the language choice (the hint “Suggest to the developer” shows on hover).
2. Choose what it is about: an idea or wish, something does not work, inconvenient or unclear, or a question.
3. Write in your own words what you did and what you expected. The more concrete, the sooner it can be done.
4. If you like, add up to three screenshots: paste from the clipboard (Ctrl+V), drop a picture, press Choose a file or Capture the screen — the browser asks which tab or window to capture. PNG, JPEG and WebP up to 8 MB.
5. Press Send to T.G. The panel shows the number of the suggestion; close it and go on working.

No need to write down the page, the study, the time or the browser: the portal keeps them, so the Portal Owner opens the same page you saw.

My suggestions: the tracker

You can open the list at any time without writing a new suggestion: “My suggestions” with their number is in the side menu (it appears after your first suggestion) and on the “Profile” page.

My suggestions: what became of each one, T.G.'s answers and your moves.

• At the top: how many suggestions you sent, how many were implemented, how many are in the plan or in progress, how many were answered and how many will not be done.
• Statuses: Received, Under discussion, Your answer is needed, In the plan, In progress, Done, please check, Answered, Not planned, Postponed, Closed.
• Under each suggestion is its way: your text, T.G.'s answers and questions, the release that shipped it, your additions and checks.
• Add to it works for any suggestion that is not closed. When T.G. asks a question, the suggestion is highlighted and has the field Your answer to T.G. under it.
• When a release shipped what was done, the suggestion gets the buttons It works and It did not help. “It did not help” with a short note sends it back to T.G. If you mark nothing, it closes by itself after 30 days.
• The most active participants of the beta testing will get prizes. The place counts how many of your suggestions were taken into work and done, not how many were sent; tests and repeats of someone else's suggestion do not count. You never see other people's names or suggestions.
• The news about your suggestions (an answer, a question, a release) comes in one letter, at most once a day.

Screenshots and personal data

• A screenshot must not show patients' data or other people's personal data. Close the patient card or open the demo study first.
• The screen is captured only after you allow it in the browser's window; you see the picture before sending and can remove it.
• The portal saves every picture anew and drops the file's metadata (phone model, place, author).
• Only Portal Owners see suggestions. They reach the developer only in the package for the review: without names and e-mails, and only the screenshots a Portal Owner looked at and ticked.
• The screenshots of finished suggestions are removed after 12 months (the Portal Owner can change it); the text stays.
• The text of a suggestion is not written to the audit trail: only the facts are — sending, decision, status change, package, deletion.

For the Portal Owner: whose move, and the decisions

Administration → Suggestions: the top shows whose move it is and what waits for you.

• At the top four cards: Your move (waits for the review, waits for the decision), The author's move (asking the author, done and the author checks), The build's move (we do it, in a build) and Finished or postponed. A click on a card or a status filters the list.
• On the right is the order of work: download the package for the review, upload the review, decide, and what a release shipped becomes done by itself. There are also the numbers (how many came, how many days to the decision and to the release, which share was taken into work), the topics and Who suggests.

The decision screen: on the left what the author wrote, on the right the developer's review and your decision.

• We do it — the suggestion goes into the plan, a build can be named. We answer — an answer is enough. We do not take it — with the reason: not for this portal, a test, not allowed by the rules, another one, or later (then it hides and comes back by itself on the date chosen).
• Under the buttons are two more decisions: Ask the author (the question shows to the author, the suggestion waits for the answer) and The same as another one with the number of the main suggestion: the repeat follows its status, and its author gets your answer.
• The field Answer to the author already holds the answer of the review in the author's language; edit it if needed. The author sees it at once.
• Waiting for the decision lists every reviewed suggestion by topic, with the developer's recommendation and the answer ready. Untick the ones you want to decide yourself and press Take the recommendations of the ticked.
• Every decision goes into the audit trail under your name, with the date and the reason. At the bottom of the screen you can correct the status by hand and keep a note only Portal Owners see.

The package for the review and the developer's review

The package for the review: you see what leaves and tick the screenshots yourself.

• The portal sends nothing anywhere by itself and uses no AI. You download the package for the review and give it to the developer.
• The package holds what changed since the last one: new suggestions, the authors' additions and “did not help”, your decisions, and what is planned for the build.
• Instead of the author's name the package has a code (for example A-3f9c2a), the same in every package; no e-mails. Only the screenshots you ticked “No personal data: let it go” go in. Every package is written down: when, who, which suggestions and screenshots.
• The developer returns a review file (JSON). Upload it with Upload the review. For each suggestion it holds the gist, what the portal already has, the cause or the size, the risks, the topic, the recommendation and the answer to the author in your name. A card is taken only for the suggestion it was written for: the number and the fingerprint of the text must match. The rest are skipped, and the portal says which and why. Critical problems are shown apart.

The release, the author's check and the traceability

• When the developer takes a suggestion into a build, the next review moves it to In a build with the build and the pull request.
• A release carries the list of what it did. After the install those suggestions become Done, the author checks with the version by themselves, and the author gets a letter asking to check.
• Traceability by release shows for each release which suggestions it shipped, who decided and when, which build and pull request, and whether the author confirmed it. The Excel table can go into the validation file of the release.

Letters and settings

• Letters about new suggestions. Enter the addresses (one per line, up to 10): every new suggestion, an author's addition and “did not help” come there by e-mail with the text and a link. Screenshots are not attached, since they may show personal data. Until the list is saved, the letters go to the address set on the server at installation, else to the portal's admins; a saved empty list sends none.
• A weekly reminder to the same addresses: how many suggestions wait for the review and the decision, and how many days the oldest one waits. Untick it in the Tracker settings.
• There too: how many months to keep the screenshots of finished suggestions (0 keeps them for ever).
• The Excel and CSV exports have the authors' names: they are for your own work, not for sending on.
• The button can be switched off for everyone or for some people in Functions and limits (the function “Suggest to the developer”). By default one person sends at most 30 suggestions a day.