Contributing code to the Core: Approaches /Mechanisms We Need Your Input

Implementing
1

Hey Everyone

We would like to better understand current approaches that implementations are taking to contribute code/ features back into the core .

  1. What has been the current practice in the community?
  2. What approaches do implement’s and the community at large feel could enable easier contributions?

In addition to the 2 questions above, If your implementation has existing code that could meet the features listed in our Road-map for Ref 2.10 We would love to hear from you on how best we could get access to the code and integrated into this release under development. (If it is already in the Github repository somewhere, do point us in that direction too :slight_smile:

Please post your comments in this thread.

@ball @ssmusoke @k.joseph @ningosi @janflowers @jdick @mseaton @mogoodrich @chris

2 Likes
2

The approach that i have seen taken by some implementations like UgandaEMR is, to avoid doing anything in their implementation specific modules, that could be shared with the rest of the community. As a result, they have been adding such features or bug fixes directly to the community supported modules. Hence, they do not carry the burden of having to maintain it themselves. @ssmusoke :slight_smile:

One of the things that i have been doing, and we could do even better, is to give a higher priority attention to such pull requests. To be specific, when implementation developers raise pull requests about things that they need, i have been reviewing and merging them faster than the rest of the pull requests which are not driven by direct implementation needs or requests. That way, they feel motivated and encouraged to directly contribute to the shared pool.

We have also had to bend some of our rules to make it easier for implementations that contribute. To give an example, we generally do not back port new features to maintenance branches. But Mekom Solutions implemented this https://issues.openmrs.org/browse/TRUNK-381 and at that time, could only upgrade to a maintenance release. So we back ported it. @mksd

I would like us to look into ways of making it easier for implementations to advertise what they have done such that we get to know what we may need to harvest from them, when they do not have resources to contribute it back. The reference application is mostly a harvest from what @PIH had developed for their implementation.

5 Likes
3

I think that’s great. Do you feel you have enough visibility on this? I mean, do you feel you have access to the info that you need to find out whether a PR is bound to some, possibly pressing, implementation work?

1 Like
4

@dkayiwa thanks for your input.

On top of what you said I see some nuances

  1. A way for implementations to share what they have developed and are willing to share

  2. Faster identification and review of implementation specific PR when they do arise

3.Resources to harvest the code

to @mksd question in the previous post , do we have enough visibility to know whether a specific PR is related to an implementation? If not how could we improve this?

5

I have been able to tell such pull requests basing on the ticket conversations and talk posts that led to them.

1 Like