Topic: Sync Module
Type of Project: Sprint
Dates: Thursday, March 14 - Wednesday, March 27 2013
Product Owner: Lara Kellett
Developer Lead: Mike Seaton
Sprint Dashboard: https://tickets.openmrs.org/secure/RapidBoard.jspa?rapidView=29
Source code at: https://github.com/openmrs/openmrs-module-sync
How to Participate
We will be holding a Sprint kickoff meeting on Thursday, March 14 at 3pm Eastern Time. This Sprint kickoff will be held using Google Hangout and broadcast for later playback on the OpenMRS Youtube channel.
Following the kickoff, all discussions related to the Sprint will happen via the OpenMRS IRC Channel. If you would like to get involved in the Sprint, simply connect to the IRC channel and engage with the developer lead (on IRC as "mseaton") or one of the other developers who are working on the Sprint.
There will be a daily scrum updates for all participants, per the normal Scrum schedule. This will occur over IRC each day at 10am Eastern Time except for Thursdays, when the scrum is at 3pm due to the weekly developer forum that takes place at 10am.
All work done within this Sprint should be done from the list of available tickets found on the Sprint dashboard. Available tickets are listed roughly in order or priority, so if there is any doubt as to which ticket to work on, please start from the top of the list. Please only claim tickets once you have started working on them, and unassign yourself if you find that you are unable to complete a ticket once you have picked it up, so that others can take over.
For developers who are new to OpenMRS or who are new to the Sync module and want to ease into it, there are many introductory tickets included in the sprint for you to choose from. You can filter for these tickets directly using this link, or you can click on the "Quick Filter" called "Intro Tickets" from within the Sprint dashboard.
Working with the code:
During the course of this Sprint we will all be working from a common branch, named "sprint201303" and committing directly to it, to ease collaboration, review, and release. Please do _not_ commit directly to the master branch without prior discussion with the team. For general help with using git and the OpenMRS development process, you can check out this section of the wiki. Specifically, the process you should follow is:
- Clone the project into your workspace: git clone https://github.com/openmrs/openmrs-module-sync
- Checkout the sprint201303 branch: git checkout sprint201303
- Claim a ticket by assigning it to yourself
- Do your work, committing changes locally
- Frequently rebase your code to ensure you are picking up everyone elses changes: git pull --rebase
- When you feel your work is complete, squash each of your commits into a single commit, and push your commit, referencing the ticket number in your commit message
- Mark your ticket as done, ready for review by doing: "Workflow -> Committed code" in JIRA, and referencing your commit in the comment.
- Iterate on steps 4-6 as needed, depending on any code review comments that come back
Alternatively, if you wish to follow a classic process of forking the code to your own github repository, working within feature branches, and issuing pull requests, this is fine too.
Must: (eg. the driver for the Sprint)
SYNC-287: Prevent sync module from persisting changes if no sync record is created
SYNC-295: Transmit and store information related to incoming sync records
Should, medium-or-high complexity:
SYNC-291: Better handling of re-sending sync packages after failures
SYNC-292: Provide more granular filtering on the history of changes page
SYNC-294: Ensure outgoing sync error details are properly logged and available to the administrator
SYNC-296: Support the ability to sync Lists
Should, low complexity:
SYNC-272: History of Changes: Records per page should not set "firstRecordId" if not previously set
SYNC-293: Add quick link on history page to "Most recent all committed"
SYNC-290: Sync Statistics page throws an error upon loading
SYNC-289: Show current time on the overview page
SYNC-288: Add sync record id to the history of changes page
Also: Lots of tickets around failing unit tests that could be reasonably tackled