Registration Core Module Sprint

Owned by Kiran Reddy
Last updated: Dec 14, 2012 by Chris PowerVersion comment
5 min read

Topic: Registration Core Module

Lead (Product Owner): @Jeremy Keiper

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

Date: 14 Dec 2012 - 21 Dec 2012

Participants

  • @Jeremy Keiper (lead)

  • @Wyclif Luyima

  • @raff

  • @Daniel Kayiwa

  • @Wesley Brown

  • Your Name Here

Overview

This module will provide basic registration services for other modules to use when registering new patients. It will not have a UI of its own aside from administrative management, but will eventually provide UI widgets to facilitate building a registration form in another module. The objective of this module is to hone the registration process to a single methodology, so an implementation can focus on the data being collected rather than how use the various API services to create all necessary data involved in the process of registration.

Please clone, compile and read up on the AMRS Registration Module. This is not a reference application, but is an example of a functioning registration module. Pay attention to how filling out the form affects the search results, how a user might interact with it and what code is used in the controller. My hope is that most of this controller code will be replaced with simple calls to methods in the new Registration Core Module.

After this, please fork the OpenMRS Registration Core Module to your repository so we can begin work together.

Links:

Goals

Must Have:

  • A new Registration Core Module with search and registration services in the API

  • Tie-in with IDGen module for rendering identifiers

  • Tie-in with the Event Module to signal registration events

Should Have:

  • A way to validate a registration event by imposing restrictions on the minimum data set required, initially via code

  • Search widget for other modules to drop into registration forms

Could Have:

  • Administrative UI for specifying the minimum data set

  • AJAX and/or REST exposure of the API services

Won’t Have:

  • Full UI for registering a new patient

Kickoff Meeting

Kickoff meeting Date: 14 Dec 2012 9:30am Eastern Time in #openmrs on IRC

(Meeting setup with known developers after the final design meeting, but prior to the start date):

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)

    2. Have we cleared the decks of all other distractions? 

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. 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.

  3. If you have any questions about the ticket, ask on the group chat

  4. Do the ticket. See our HOWTO 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.

  5. Join the daily scrum to share your updates

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

Tickets involved:

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)

Resources