Versions Compared

Old Version 24

changes.mady.by.user Daniel Kayiwa

Saved on

compared with

New Version Current

changes.mady.by.user Daniel Kayiwa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

...

  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

Design

Info

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

Looking at creating 3 parts (Possibly 2/3 different sprints)

1.  Structure issues w/OpenMRS and Pair program

1 Core Dev in a complementary timezone

2.  Get more people involved with core features

This is where the community gets involved

3. Once in place some feedback from users to make changes.

Looking to see if we an build this incrementally

1.  A separation of API and UI

Design Call 11/7 Proposal

  1. Start small (example Create and appointment)  Layout the design for that.  Concern is that if it's too basic will it get used?  Discussion on this is needed.
    1. Creating a table in DB
    2. basic UI
  2. Get the developers on some specialize bugs to fix
  3. Happy with the design for the 1st feature
    1. Possibly Daniel could schedule an hour a day to work with them setting up the project with their first feature.
      1. Talk to Daniel about scheduling  (Sunday through Thursday is the workweek)
  4. How do we guide tomorrow call correctly?
    1. Goal What's the data model needed?
      1. what are the items that needed in the DB (start, finish, date, time, location, what needs to be recorded)
    2. Some basic introductions
    3. When we get an idea of the smaller pieces figured out then how to create tickets
      1. We need to frame tickets as user stories and then have the developers build the actual tickets for code
  5. Look at existing modules to see if we can reuse (module ID: appointment) need to look at this source code to see if it has potential

...