May 17th 2016
- Kevin Cussen (Deactivated)
Attendance Information
5/17/2016
8AM PST - Seattle
11AM EST - New York, DC
5PM CEST - CEST, Geneva, Copenhagen, Joburg
6PM EAT - Dar
Meeting Number: 192 173 465
Host Key: 352864
Audio Connection: +1-415-655-0001
AGENDA
| Item | Time | Presenter |
|---|---|---|
Next steps on maturing our process for vetting project proposals (see memo & graphic) One mans thoughts: https://www.lucidchart.com/invitations/accept/2257ae2e-fab0-4751-a4a4-dd25dc7a1541 Recap of discussion with Rich Magnusson on effects of new architecture (see poorly lit picture below)
The product committee recognizes that a clear process for vetting project proposals needs to be defined. To this end, we have recently introduced a process to review new project proposals for global requirements, to investigate cross-country demand for features, and to inform what features belong in the core OpenLMIS product. Consider a 1-2 day in-person to make bylaws concrete if possible | 45 minutes | |
Acceleration Proposal Feedback Available here: OpenLMIS Re-Architecture Acceleration Brief | 5 minutes | |
| Feedback on Committee Survey | 10 minutes |
ACTION ITEMS
MINUTES
In attendance: Kevin Cussen (Deactivated), Lakshmi Balachandran, Ashraf Islam (Unlicensed), Gaurav Bhattacharya (Unlicensed), Danni Yu (Unlicensed), Chris George (Unlicensed)
Started 10 minutes late due to webex conflict with Governance committee.
Kevin Cussen (Deactivated) asked if there is a better date and time.
Ashraf Islam (Unlicensed), Lakshmi Balachandran, Danni Yu (Unlicensed) all said the date and time is fine. Ashraf Islam (Unlicensed) suggested delaying 15 minutes for governance committee overflow. All agreed. Kevin Cussen (Deactivated) will send out next invite for 8:15AM PDT / 11:15AM EST - New York, DC / 5:15PM CEST - CEST, Geneva, Copenhagen, Joburg / 6:15PM EAT - Dar
Kevin Cussen (Deactivated) described the new service based architecture, referred to re-architecture acceleration linked on this page for more information. Based on this new architecture I had a conversation with Rich Magnuson (Deactivated) about how the product committee should become involved in future partner development. From the product committee stand-point, creating a completely new service is the least intrusive (#1 in the diagram below). Only the environment needs to be aware of the new service and no other services would need to be modified. Is there agreement that the product committee should not be involved in this design.
Ashraf Islam (Unlicensed) once you guys decide on a support partner and start the architecture implementers will need to be oriented to this new way of contribution starting with the MVP in October. Would be beneficial for you guys to come up with an example scenario of adding a new service. Similar to what Drupal or WordPress does to assist new developers.
Kevin Cussen (Deactivated): The re-arch is underway - we got the thumbs up from the BMGF, SolDevelo is supporting - VR team is in Poland at present doing a mind meld. myFirstService approach sounds like good advice, will put it on the backlog. Other feedback?
Ashraf Islam (Unlicensed): Once you have the service, how do you know it isn't currently on my backlog? You'll likely have hundreds of stories and many domains. How will an implementer know if the functionality they need to build is already there or not?
Kevin Cussen (Deactivated): JIRA is open and publicly facing. Implementers are able to build their stories directly in JIRA if they desire by getting access from Rich Magnuson (Deactivated). If they want a list of upcoming features at a higher level, they can refer to the roadmap. Take a look at the re-architecture proposals which has a few screenshots of the high level roadmap and let me know if that is what you are looking for. We can discuss on the next call if not. Any dissent? (None) Any other comments?
Kevin Cussen (Deactivated) described a situation where an implementer needs to create new functionality from an extension point that doesn't yet exist (#3). They have the option of creating it themselves (and contributing back the new extension point) according to the contribution guidelines or asking the core team to create it for them. They would then built out the new functionality in a separate repo and may or may not contribute that back. Should the product committee have a say on this? To me it sounds like the answer is no. New functionality would be on the other side of the extension point and could be in a separate repo. The extension point would be part of the core, but could likely be re-used by other implementers in the future.
Lakshmi Balachandran: As long as it doesn't have a user facing impact, I don't think the product committee needs to get involved.
Kevin Cussen (Deactivated): Agreed - any dissent on no involvement for creation of an extension point? None. I actually skipped over #2 in the picture below, which is a less intrusive case of #3. In this use case, the extension point already exists and the implementer just uses it. Any objection to the product committee not becoming involved in this? (None). Ok, in the last case (#4) an implementer directly modifies a service. This could be relatively simple, such as of adding a new field to a table and could be as complex as modifying the requisition process. The general litmus test Rich Magnuson (Deactivated) and I came up with is:
As a developer, if I:
(1) Make a change that causes existing tests to fail
(2) Make a change that requires documentation to become outdated
I should involve the product committee.
Given the trivial case of adding a new field to an object, neither of these would be triggered. However, modifying the expected behavior of the requisition would require sign off from the product committee in order to be contributed back.
Ashraf Islam (Unlicensed): Implementers should be encouraged to follow guidance when they decide to modify a service. Shouldn't be a requirement that they do it any particular way or involve us. We would want to support a situation where in the future people make modules that they can sell.
(Lakshmi Balachandran had to drop)
Chris George (Unlicensed): I don't think the AGPL license allows this.
Ashraf Islam (Unlicensed): There are loopholes, i.e. transacting data through web services.
Kevin Cussen (Deactivated): There is no way we can force anyone to involve the product committee. However, if implementers want to contribute their changes, they will need to follow the rules we're laying down. Additional thoughts on #4?
Danni Yu (Unlicensed): There could be several scenarios that would prompt #4. For example, is there a conflict with existing behavior? Are we adding something new? If the existing system doesn't work, we will need to introduce a bugfix. For all of these the product committee would need to be involved. For the first, if a new country has different behavior does that mean we did the initial service non-global or that is an edge case?
Kevin Cussen (Deactivated): That's a good point - I agree. Can you give an example for the second?
Danni Yu (Unlicensed): For second case, we added ordering to stock management. This could be a global feature or not, should have gone through the product committee if it had existed.
Chris George (Unlicensed): So are devs the first line that knows about this? It seems like practically all changes to a service will go to the product committee.
Kevin Cussen (Deactivated): Is that a bad thing - we'll see. I could see a future where devs read about this in the contribution guide and inform their teams. For the present, I think the community is small enough that these conversations happen 1-on-1 amongst folks that have worked together and we're paving the path for the future. Any dissenters on these use cases and adopting them as our official stance?
(Chris George (Unlicensed) got dropped from the call)
Ashraf Islam (Unlicensed): Sounds right.
Gaurav Bhattacharya (Unlicensed): Sounds good.
Danni Yu (Unlicensed): Totally.
Kevin Cussen (Deactivated): Good - all agreed. A quick reminder that we'll meet in two weeks, 15 minutes later. Have a great week!
RECORDING
ADDITIONAL READING
OpenLMIS: the global initiative for powerful LMIS software