/
Evolving to new development practices (TECH)

Evolving to new development practices (TECH)

Oct 02, 2015

Description: Short-term approaches to identifying technical debt; how to apply new development practices now; Common shared upstream branch

Leads: Darius

Rapporteur/Notetaker:  Rich

Audio Recording:  Development Practices d2s4.mp3

Notes from Session:

Intro

In this session, we start to decide which practices to follow, and how to handle technical debt.

Who is currently contributing code?

  • TW to 2 for MOZ

  • VR, CHAI, JSI and PATH to eLMIS

High Level work to accomplish in the short term:

  1. We Commit to making 2.0 the upstream branch by end of 2015

  2. Need CI and automated reviews  (possibly need a QA environment)

  3. Updated workflows around pull requests/reviews

  4. Test data set/configuration

  5. Need 2.0 Demo instance (there are ones for TZ and MOZ projects)



What are the implications for countries between now and 2.0 master?  (Not addressed in discussion)

Tasks: (Owner is in brackets)

  1. Nominate and establish technical WG

  2. Accessibility from 1.0 is merged into 2.0 [VR]

  3. Gitflow setup (rename '2.0' to 'master', etc.) [VR]

  4. CI Server:  [VR]

  5.  

    1. Need to pick a CI:  "travis", based on github permissions.  Most orgs currently use Jenkins

  6. Sonar server [any org]

  7. Publish rules in dev documentation, a "contribution guide"

  8. Dedicated time for regular reviews, merge into master

  9.  

    1. Public expectations between organizations, who has privilege to commit to master trunk?

    2.  

      1. Write down the vetting requirements/criteria for this committer

  10. Establish tech review board, and its arbitration process

  11.  

    1. Publish Pull request process and expectations

  12. Tool selection (issues, wiki, etc.)

  13. Create test dB, demo environment



VillageReach doesn't need to do all of the above tasks.  Govern & Tech tracks should review and decide.  Tomorrow, decide Tech WG members.

 

  • Should have some upfront feature review so project knows ahead of time if a feature belongs to core or not, to set expectations and avoid surprises.  Product design should occur beforehand.

  • How is a feature, ready to be merged, defined as Done?  Any requirements around documentation, testing, etc.

    • Question arising from doc concern:  If code is merged into dev/master, what is the Done criteria?  If feature is gradually built and constantly merged in, when is that feature "done"?  Needs to at least be Done by the next release tag.

 

OpenLMIS: the global initiative for powerful LMIS software