| Wiki Markup |
|---|
h2. General Info
*Topic:* Integration of RESTWS
Type of Project (Spike, Sprint, Epic): ?
*Lead (Product Owner): Roger*
*Developer Lead: Rafal*
*Known Developers Assigned (amount of effort in hrs dedicated to this work if possible): *
*Sprint Dashboard:*
*Source code at:*
{color:#000000}{*}Date:*{color}
h2. How to Participate
*This first sprint for the Appointment module will not be advertised to the whole community however those interested in working with us on future sprints should contact us\!*
Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.
The general process:
# New to OpenMRS sprints? Want help getting started? Join {color:#856628}\[the IRC channel{color}\|IRC:\] and say "{color:#000000} {color}???": I'd like to participate in the sprint\!"
# Pick a ticket from the available tickets in the top-left of the sprint dashboard page. (listed below)
#* Make sure it does not depend on a ticket that is incomplete.
# If you have any questions about the ticket, ask on the group chat
# Do the ticket. See our {color:#856628}\[HOWTO{color}\|docs:Using Git\] for git. *Sprint specific git HOWTO for devs with push rights: whatever works for you \:-)* If you don't like pull requests, don't send them. Commit and push directly to the main repo. If you do like pull requests, fork the main repo and send pull requests, but merge them right after. My favorite way is to work on the main repo, but create local branches (without pushing them to the main repo). Merge branches locally to the master and push to the main repo.
\# {color:#856628} {color}\[{color:#856628} {color}Join the daily scrum to share your updates\|https://wiki.openmrs.org/display/RES/Daily+Scrum+Meeting\]
h2. {color:#3366ff} {color}Tasks To Be Completed Prior To Design
{composition-setup}cloak.toggle.type=wiki{composition-setup}
h2. Goals
{toggle-cloak:ID=Goals}
Need to know more about {color:#3366ff}Goals{color} ? Click here
{cloak:ID=Goals}
*Goals:* _Must Have, Should Have, Could Have and Won’t Have_
*Must Have* means we must have this as part of the solution. It is a requirement or we should rethink doing this work. *{+}This is what we will deliver before the end of the work period{+}* this also doubles as our DOD “Definition Of Done”
*Should have* means we would be embarrassed not to have it. We could technically produce the solution without it but people would be surprised.
*Could have* means anything else we could do. But this does not always mean low priority. But our selection of which could haves to include or exclude (or deliver later). Also is considered low hanging fruit (if we are in this code already for _x_ reason wecan deliver _y_ with little or no extra effort) or can be items or ideas for this module that can be packaged for a later spike or sprint.
*Won’t Have* means this will not happen. It might be technically impossible, a taboo for our organization or out of scope. It does not mean “might happen or would be nice”.
{cloak}
{color:#222222}{*}Must: (eg. the driver for the Sprint)*{*}{color}
{color:#222222}SYNC-287: Prevent sync module from persisting changes if no sync record is created}{*}Should{*}{color}
{color:#222222}SYNC-295: Transmit and store information related to incoming sync records{*}Could{*}{color}
{color:#222222}{*}Should, medium-or-high complexity:*{color}
{color:#222222}SYNC-291: Better handling of re-sending sync packages after failures{color}
{color:#222222}SYNC-292: Provide more granular filtering on the history of changes page{color}
{color:#222222}SYNC-294: Ensure outgoing sync error details are properly logged and available to the administrator{color}
{color:#222222}SYNC-296: Support the ability to sync Lists{color}
{color:#222222}{*}Should, low complexity:*{color}
{color:#222222}SYNC-272: History of Changes: Records per page should not set "firstRecordId" if not previously set{color}
{color:#222222}SYNC-293: Add quick link on history page to "Most recent all committed"{color}
{color:#222222}SYNC-290: Sync Statistics page throws an error upon loading{color}
{color:#222222}SYNC-289: Show current time on the overview page{color}
{color:#222222}SYNC-288: Add sync record id to the history of changes page{color}
{color:#222222}Also: Lots of tickets around failing unit tests against 1.10 that could be reasonably tackledWon't{*}{color}
h2. {color:#3366ff}Design{color}
{toggle-cloak:ID=Design}
What should go into a {color:#3366ff}Design{color} ? _Click here for more information_
{cloak:ID=Design}
There should be multiple design meetings. The first starts off with a small group working with the leader to determine the high level scope of the project and then to break down into smaller pieces to eventually place as tickets. Once those meetings havehappened use of the community design meeting time should be used to refine the tickets and if possible assign them to who will be doing the work.
{color:#000000}{*}Risks{*}{color}{color:#000000} {color}(these should be resolved prior to or during the design meetings):
{color:#000000}{*}Enter anything that is still questionable or worrisome that has not been answered:*{color} (open issues, potential concerns) Once a decision is made make sure that a summarized answer is included.
Example: Q. How will we handle issues with conflicting userID’s? A. All ID’s will have an added identifier that is unique.
{color:#000000}{*}Effort Accounted For:*{color} (At the end of the design call all tickets should have an estimated effort and that total should be balanced against the known available effort of the developers assigned) (Yes/No)
If not in balance in favor of success why and the action plan for remaining items
via IRC on the {color:#856628}\[#openmrs{color}\|IRC:Home\] channel on freenode.
Use this channel for *ALL* debugging and random questions having to do with the sprint. Please avoid direct messaging to personal contacts. If you have a question, someone else most likely does too, and our geographically distributed community benefitsfrom public group discussion.
*Sprint Break down:* If tickets have not already been laid out or explained this is a good place for this.
{cloak}
{color:#000000} {color}{*}Risks*: ?
{color:#000000}{*}Enter anything that is still questionable or worrisome that has not been answered:*{color} ?
{color:#000000}{*}Effort Accounted For:*{color} {color:#000000}?{color}
*Sprint Break down*: ?
h2. {color:#3366ff}Kickoff Meeting{color}
{color:#000000}{*}Kickoff meeting Date:*{color}{color:#ff0000} {color}TBD
*Kickoff meeting recording:*
*(Meeting setup with known developers after the final design meeting, but prior to the start date):*
{iframe:src=http://notes.openmrs.org/PatientSummaryKickOff\|width=100%\|height=650px}{iframe}
h2. {color:#3366ff}During Project Notes{color}
{toggle-cloak:ID=Notes}
{color:#3366ff}Notes{color} _(Click here to expand to Etherpad)_
{cloak:ID=Notes}
\\
{iframe:src=http://notes.openmrs.org/PatientSummary\|width=100%\|height=450px}{iframe}
\\
{cloak}
h2. {color:#3366ff}Post Project (Retrospective){color}
{toggle-cloak:ID=Retrospective}
{color:#3366ff}Retrospective{color} _(Click here to expand to Etherpad)_
{cloak:ID=Retrospective}
\\
{iframe:src=http://notes.openmrs.org/PatientSummaryRetrospective\|width=100%\|height=450px}{iframe}
\\
{cloak}
h2. {color:#3366ff}Resources{color}
Additional Information:
h2. Goals
* The purpose of this sprint is to clean up the way we've done RESTWS, by merging the two modules into one. There was a dev list thread where we discussed this. The particular question is that there are two different ways we could do this.
h2.
h4.
h4. Approaches
Jeremy and Roger have a suggested approach. We are currently looking to see if anyone else is willing to weigh in.
\\
h2. How to Participate
Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.
The general process:
# New to OpenMRS sprints? Want help getting started? Join [the IRC channel|IRC:] and say "{color:#000000}???{color}": I'd like to participate in the sprint\!"
# Pick a ticket from the available tickets in the top-left of the sprint dashboard page. (listed below)
#* Make sure it does not depend on a ticket that is incomplete.
# If you have any questions about the ticket, ask on the group chat
# Do the ticket. See our [HOWTO|docs:Using Git] for git. *Sprint specific git HOWTO for devs with push rights: whatever works for you \:-)* If you don't like pull requests, don't send them. Commit and push directly to the main repo. If you do like pull requests, fork the main repo and send pull requests, but merge them right after. My favorite way is to work on the main repo, but create local branches (without pushing them to the main repo). Merge branches locally to the master and push to the main repo.
# [Join the daily scrum to share your updates|https://wiki.openmrs.org/display/RES/Daily+Scrum+Meeting]
h3. Participants
* Rafal
h2. Resources
Tickets: RestWS-310 (still left to complete)
Kickoff meeting recording: ?? |
Page Comparison
Manage space
Manage content
Integrations