| Table of Contents | ||
|---|---|---|
|
Attendees
- Brandon Bowersox-Johnson
- Nick Reid
- Mary Jo Kochendorfer
- Josh Zamor
- Sebastian Brudziński
- Weronika Ciecierska
- Ben Leibert
Performance-Related Tickets
Malawi's tickets weren't always clear because were were rapidly making decisions. The tickets thus drifted - a delta developed between what they said and how the team understood they had to be implemented. They were thus confusing to outsiders. We, which is a problem we're trying to avoid this problem in the future.
Rejection-Status Pull Request
The "REJECTED" status ticketed was also a pain point. We were told that the work could be done and would be accepted into core. This wasn't the case , though: it took two weeks from the time the PR was made until the time Core approved the business related changes it madeintroduced. This caused a problem when the code eventually was merged , because its dependencies had changed. We were lucky it was simple to address the this problem.
The core team learned from the "REJECTED" status ticket that we should perhaps do things more formally. Once the pull-request was made, we realized that we couldn't fully communicate the all its changes to all stakeholders. We could have better communicated initially that we needed more business analysis and buy-in from stakeholders. Needed to be communicated to product committee.
...
- Update documentation for pull requests to be pulled in. Questions might be:
- Does it need to be shared with and reviewed by the product committee?
- Does it change the UI in a meaningful way?
- The documentation should help us to set expectations around timing. The timing we've adopted for Malawi won't likely be typical.
Code Review Process
Q: Some large pull-requests are being approved/merged very quickly. Are they being given enough attention prior to the merge?
...
- Perhaps incoming work should be put on the Core's JIRA project, and explicitly reviewed during sprint showcases. Otherwise, these additions are largely invisible to team.
- Another idea is to merge the Core and Malawi JIRA projects into one. The teams could still work independently and on different sprint cycles. This would improve work visibility as well as velocity-tracking.
- CI/Jenkins Issue: The Pull Requests are not tested by Jenkins, so developers have no immediate feedback of any failures or issues. (Compare that to core team process of contributing draft work immediately to master, where Jenkins gives immediate feedback if any test failures or issues.)
- Suggested Documentation: Monthly/periodic releases. PRs get reviewed as a priority; large ones may take longer. Once PRs are approved and merged in, they are available in SNAPSHOT versions of services right away, and will be in the next official monthly official release. It's best to have on-going dialogue between the two teams so there is awareness of the upcoming release dates. Implementations should not build an expectation that releases will happen quickly or immediately.
- Suggest adding sentence about timing into our docs: http://openlmis.readthedocs.io/en/latest/contribute/contributionGuide.html#coordinating-with-the-global-community
Malawi's Git Repositories
Q: Question
Has it been problematic for MW to use/share core's OpenLMIS github organization? It requires copying-and-pasting code from one repo to another, and that may lose intervening changes. And it loses the commit history.
A: Answer
Another issue is that one pull request can depend on another, causing problems.
...