General Info
...
- New to OpenMRS sprints? Want help getting started? Join the IRC channel and say "???": I'd like to participate in the sprint!"
- Checkout code:
- Fork https://github.com/openmrs/openmrs-module-webservices.rest
- Clone your fork: git clone https://github.com/YOUR_USERNAME/openmrs-module-webservices.rest.git
- Add upstream: git remote add upstream https://github.com/openmrs/openmrs-module-webservices.rest.git
- Fetch all branches: git fetch --all
- Checkout the sprint branch: git checkout sprint-201302
- Compile code:
- Run: mvn clean install
- Setup OpenMRS. Get the standalone:
- Unpack and start openmrs-standalone.jar. Choose the demo database.
- Go to http://localhost:8081/openmrs-standalone/admin/modules/module.list and upload a compiled webservices.rest omod, which you can find in webservices.rest/omod/target.
- 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
- Create a local branch for your ticket (see also our HOWTO for git, use 'sprint-201302' instead of 'master')
- git checkout -b REPORT-123 sprint-201302
- git push origin REPORT-123
- Do the ticket.
- Stage changes: git add -i
- Commit: git commit -m "REPORT-123: ticket title"
- Push changes: git push -f
- Issue a pull request for the 'sprint-201302' branch (see github help) or if you have push rights: whatever works for you! If you don't like pull requests, don't send them. Commit and push directly to the upstream repo. If you do like pull requests, fork the repo and send pull requests, but merge them right after. My favorite way is to work on the repo, but create local branches (without pushing them to the repo). Merge branches locally to the sprint branch and push to the repo.
- If you push directly to the repo check if tests for the sprint branch in reporting are passing: https://ci.openmrs.org/browse/BUNDLED-RESTWS0 (Favorite the branch to be notified about failures: Login into Bamboo, Choose Actions -> Favorite Branch)
- Join the daily scrum to share your updates
Participants
| Wiki Markup |
|---|
{composition-setup}cloak.toggle.type=wiki{composition-setup} |
Goals
| Wiki Markup |
|---|
{toggle-cloak:ID=Goals} |
Need to know more about Goals? Click here.
...
Goals: Must Have, Should Have, Could Have and Won’t Have
...
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”.
| Wiki Markup |
|---|
{cloak} |
Must Have:
- Just one module for "core OpenMRS REST Web Services" (i.e. get rid of 19ext module)
- the resources need to be separate from the framework (even if this just means that they're in different Java packages)
- the resources defined against 1.8 should be in a different java package from the ones defined against 1.9, etc.
- This is mostly done, but still need to create tickets about fixing tests, and fixing some resources
- Need to have both 1.8 and 1.9 versions of the Concept resource, which support different functionality with regard to mappings
- RESTWS-267
...
- RESTWS-311 - RESTWS should allow modules to add custom searches to existing resources** DJ: I see this as a Could, unless Roger provides a concrete example where this is needed now.** Roger: I think RESTWS-267 is an example of this. (DJ: But that's core...)** Roger: this needs "core design resources"** Decision => During the spring Rafal (or someone with equivalent knowledge and ownership of the RESTWS framework) will take this ticket.
- Support for TestOrder, and new columns in Order, starting in 1.9.2.** Do an example of how to handle out-of-band data model change** Prove this doesn't break things
Won't Have
Design
...
...
Design
...
What should go into a Design ? Click here for more information
...
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.
Risks (these should be resolved prior to or during the design meetings):
...
If not in balance in favor of success why and the action plan for remaining items
via IRC on the [#openmrs|IRC:Home] channel on freenode.
...
REPORT-114 - Support running a report multiple times for a range of parameter options and merge these results into a single output document
...
...
{cloak}Risks: ?
Enter anything that is still questionable or worrisome that has not been answered: ?
...
(Meeting setup with known developers after the final design meeting, but prior to the start date):
...
| Iframe | ||
|---|---|---|
|
...
|
...
|
...
|
...
|
...
...
During Project Notes
...
Notes
...
Notes (Click here to expand to Etherpad)
| Wiki Markup |
|---|
{cloak:ID=Notes} |
...
| Iframe | ||
|---|---|---|
|
...
|
...
|
...
|
...
|
Post Project (Retrospective)
...
Retrospective (Click here to expand to Etherpad)
| Wiki Markup |
|---|
{cloak:ID=Retrospective} |
...
| Iframe | ||
|---|---|---|
|
...
|
...
|
...
|
...
|
Resources
Additional Information:
...