Collaborative Development Mechanisms (TECH)

Owned by Kevin Cussen (Deactivated)
Last updated: Oct 02, 2015 by Rich Magnuson (Deactivated)
2 min read

Description: How to define coding standards (documentation, tests, style); Pull request process

Leads: Ashraf, Darius

Rapporteur/Notetaker:  Rich

Audio recording:  Collaborative Mechanisms d2s3.mp3

Notes from Session:

Coding Standards, Pulls, etc.

  • Once the branch is ready for a 2.0 tag, how do we continue with work?
  • Idea #1:  Use Gitflow
  • Discussion on branch management. 
    • After tag master branch as 2.0, new projects start from here and merge back frequently.
    • Who reviews the pull request?  This comes with overhead
    • Consider shared "develop" branch, esp. for short term.


  • What happens if technical WG decides a pull request should not be merged back?
    • If code/feature is not core/global, then the implementing team needs to create an extension point or some other mitigation
    • Could have a "code review window", scheduled times when others are available as reviews
      • In OpenMRS, three people are dedicated as full time reviewers, etc. for a period
      • VR could have more active pull request review roll, as VR has some level of community funding
        • Could merge, say weekly. Accept or reject (with comments back to owners),
        • Also review ad hoc pull requests
        • Decide release tags.  Master is not strived to be stable 100% of the time
        • Concern of overhead, esp. if rejections are involved.  This is part of the open source tax.
        • A technical working group ("security council") resolves disputes.  Needs an escalation process
        • Good practice is to avoid long running feature branches


  • What are the standards for merging into master?
    • Feature alignment - is the feature applicable to global/core?
    • Code quality check(coverage, tests pass, code style standards, etc.).  This can be automated.
    • It is not checking low-level stuff, e.g. code formatting.  
  • Need CI, Sonar server, etc. to help with automation

 

  • Concern about who is watching out for the integrity of OpenLMIS, e.g. technical guidance, high-level feature review.
  • OpenLMIS needs a Technical Leadership Working Group to help guide OpenLMIS tech and feature roadmap
    • Darius:  This is good for short term.  Also need a single person to act as "chief architect" for the product (and also a "chief product manager")

 

 

 

 

OpenLMIS: the global initiative for powerful LMIS software