Reporting Sprint

Topic: Reporting Sprint

Product Owner: Mike Seaton

Developer Lead: raff

Known Developers Assigned (amount of effort in hrs dedicated to this work if possible):

Date: 1/9 to 1/23

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:

1. New to OpenMRS sprints? Want help getting started? Join the IRC channel and say "???": I'd like to participate in the sprint!"
2. Checkout code:
   1. Fork https://github.com/openmrs/openmrs-module-reporting 
   2. Clone your fork: git clone https://github.com/YOUR_USERNAME/openmrs-module-reporting.git
   3. Add upstream: git remote add upstream https://github.com/openmrs/openmrs-module-reporting.git
   4. Fetch all branches: git fetch --all
   5. Checkout the sprint branch: git checkout sprint-201301
3. Compile code:
   1. Run: mvn clean install
4. Setup OpenMRS. Get  the standalone: http://sourceforge.net/projects/openmrs/files/releases/OpenMRS_1.9.2/openmrs-standalone-1.9.2.zip/download
   1. Unpack and start openmrs-standalone.jar. Choose the demo database.
   2. Optionally load demo reports using this sql. It can be loaded with mysql client. DB connection details can be found in openmrs-standalone-runtime.properties in the standalone directory.
   3. Go to http://localhost:8081/openmrs-standalone/admin/modules/module.list and upload a compiled reporting omod, which you can find in reporting/omod/target.
5. 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
6. Create a local branch for your ticket (see also our HOWTO for git, use 'sprint-201301' instead of 'master')
   1. git checkout -b REPORT-123 sprint-201301
   2. git push origin REPORT-123
7. Do the ticket.
   1. Stage changes: git add -i
   2. Commit: git commit -m "REPORT-123: ticket title"
   3. Push changes: git push -f
8. Issue a pull request for the 'sprint-201301' 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.
9. If you push directly to the repo check if tests for the sprint branch in reporting are passing: https://ci.openmrs.org/browse/BUNDLED-REPORT0 (Favorite the branch to be notified about failures: Login into Bamboo, Choose Actions -> Favorite Branch)
10. Join the daily scrum to share your updates

There are 3 primary goals we would like to accomplish during this sprint:

• Enable all reporting metadata to be shareable across OpenMRS instances using the metadatasharing module: REPORT-464
• Enable reporting to expose it's relevent data definitions as Calculations via the Calculation module: REPORT-461
• Improve the reporting module documentation on the OpenMRS wiki and prepare an OpenMRS University screencast: REPORT-463

There is also a significant backlog of tickets, of all levels of complexity, suitable for new and experience developers to contribute.

Kickoff Meeting Checklist

1. Do we know where we are going? (Yes/No)
   1. Do we know the problem we are solving (yes/no). 
   2. Do we have a complete backlog of items to complete this work? (yes/no)
   3. Do we know our scope and priorities? (yes/no)
   4. Have we defined success? (yes/no)
2. Do we know how to get there?
   1. Do we have any unknowns to be decided during the sprint? If Yes what are they?
   2. Do we know who is doing what on our project? (yes/no)
   3. Do we have a test to complete prior to completion beyond our normal submit process? (Yes/No).
   4. Do we have a high level architecture that is understood by the whole team? (This page fully completed will accomplish this)  (Yes/No)
   5. Do we know the biggest constraint that is likely to inhibit our success? (Yes and no) If no what is it?
   6. Is this a part of a larger story or epic? (Yes/No) If Yes please link
3. Are we set up to succeed?
   1. Do we have the right people? (yes)
4. Have we cleared the decks of all other distractions? 

Backlog 

These are a combination of parent tickets with child tickets underneath to break up the work or tickets needed for completion of the work.  These tickets should be made in as much detail as possible going into the design calls through use of the mailgroups and small group design meetings.  Larger design calls will be used to answer questions these groups cannot or for the community to resolve.

All tickets should have in their description a DOD (Definition of Done) or what it should have accomplished

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.

via IRC on the #openmrs 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.

During Project Notes

Post Project (Retrospective)