May 31st 2016

Attendance Information

5/31/2016

8:15AM PST - Seattle

11:15AM EST - New York, DC

5:15PM CEST - CEST, Geneva, Copenhagen, Joburg

6:15PM EAT - Dar

Link: https://meetings.webex.com/collabs/#/meetings/detail?uuid=M299H1X42RL8F1ABXL3LOKN9TN-3O29&rnd=99798.011318

Meeting Number: 192 173 465

Host Key: 352864

Audio Connection:  +1-415-655-0001 

AGENDA

ACTION ITEMS

MINUTES

In attendance: Kevin Cussen (Deactivated), Gaurav Bhattacharya (Unlicensed), Chris George (Unlicensed), Ashraf Islam (Unlicensed), Danni Yu (Unlicensed), Brian Taliesin

Kevin Cussen (Deactivated) gave a brief review of what we had discussed last time, specifically around the 4 approaches to modifying OpenLMIS and then contributing back. If a partner finds themselves in situation 4 (see previous meeting - May 17th 2016), how do we as the Product Committee handle that situation?

Chris George (Unlicensed): I suggest using the mailing list for initial discussions and jump on an ad hoc product committee call if needed. 2 weeks delay may be a bit long. The partner or PC member closest to the project should send an email to the list for discussion. 

Ashraf Islam (Unlicensed): Is the feature on the roadmap? For technical assistance involve the tech committee.

Kevin Cussen (Deactivated): What if it isn't on the roadmap and the partner is building it without needing additional help? Should we consider augmenting their team with an additional part time dev resource or another role?

Ashraf Islam (Unlicensed): May not be practical for the particular project. 

Kevin Cussen (Deactivated): Does this committee have strong feelings about adding personnel to a project at some low level of effort or are we just gatekeepers in the process?

Chris George (Unlicensed): I think we're the gatekeepers. 

Gaurav Bhattacharya (Unlicensed): We don't know how these situations will play out. We shouldn't make promises but should keep the door open for helping partners develop really important features depending on what resources the partner has. 

Ashraf Islam (Unlicensed): Agreed with Chris and Gaurav.

Brian Taliesin: No objections.

Kevin Cussen (Deactivated): Great, so for the time being we will not offer up any additional resources but we'll keep it in our back pocket for future cases.

Ashraf Islam (Unlicensed): In time we should have guidelines and quality guidelines. If we say we're not going to include a feature in the core, we should have a checklist saying why. It's important that it isn't an arbitrary process.

Kevin Cussen (Deactivated): Are you describing technical or product guidelines?

Ashraf Islam (Unlicensed): Both, for contributing code and ideas.

Kevin Cussen (Deactivated): There is some tech framework in place for that checklist. Features have to meet the style guide and be contributed in alignment with the contribution guide too. How do we do this as a product committee though? How do we vet things that are not on the product roadmap? What does that checklist look like for adding something to the roadmap when a new partner brings it?

Gaurav Bhattacharya (Unlicensed): 

Brian Taliesin: One suggestion, we have a rotating point person that is up for reviewing incoming pieces? Assigned for a month at a time, they do the initial triage of a feature, decide:

1. add to backlog

2. deny

3. discuss with the entire Product Committee

Gaurav Bhattacharya (Unlicensed): Makes sense to me. We should document on the next call why a feature was added to the backlog or not. 

Brian Taliesin: When the point person is contacted by a vendor or partner building a feature, the point person should schedule a quick call with the vendor. Discuss what that new request looks like. Write up a quick email describing the feature along with reasons to believe / reasons to doubt and plan to discuss on an upcoming call or defer. 

Gaurav Bhattacharya (Unlicensed): At what point should the Product Committee coordinate with the Technical Committee?

Kevin Cussen (Deactivated): I've had this conversation with Rich Magnuson (Deactivated) before - his preference was to have knowledge of new features at the high level requirements phase but that the Technical Committee doesn't need to get involved until the the low level requirements are available.  

Chris George (Unlicensed): Should we have a mixed Product Committee and Technical Committee meeting once a month? Rather than a point person, maybe VR should coordinate for now because they are in the same room. 

Kevin Cussen (Deactivated): I don't know how useful a once a month cross meeting would be right now - maybe moreso once we have more projects being built on OpenLMIS. For the time being I would suggest keeping it ad hoc. For the sake of making the OpenLMIS Community sustainable after our grant runs out, I would prefer not having explicit coordination activities for VR. 

Gaurav Bhattacharya (Unlicensed): Is the community manager the coordinator for what projects are happening and where features are being built? A feature coming in will require a bit of background. What countries are interested in the feature? Is anyone else building the feature elsewhere? 

Kevin Cussen (Deactivated): Perhaps, I don't know that the Community manager role would necessarily have a BA background though. That person would certainly have a knowledge of the projects being done but may not be able to compare features apples to apples.

Chris George (Unlicensed): As a soon to be point person, how do I find out about projects? 

Kevin Cussen (Deactivated): Good question - also brings up the question does the rotating point person make sense if one of us is working on the project? For example, if CHAI is working on a project and Lakshmi and Gaurav are familiar with the project, why would Brian be the point person?

Brian Taliesin: It makes sense that for a project an organization with representation on the Product Committee is executing, there is no additional point person. For external, the point person is chosen each 1 month. 

Gaurav Bhattacharya (Unlicensed): Rotate by volume, once someone has gotten an item, then it passes to the next person.

Kevin Cussen (Deactivated): I think this makes more sense. Any dissent?

Kevin Cussen (Deactivated): Ok, now that we've got agreement on who is responsible for gathering information on features and discussing them - how do we decide whether they should be on the backlog?

Brian Taliesin: Unless it absolutely shouldn't be on the backlog, a simple high, medium, low vote should suffice. Each member states where on the backlog it should be.

Kevin Cussen (Deactivated): Great - any dissent? (none). Once the feature is in development, how involved should we stay in the development of the feature?

Chris George (Unlicensed): Point person on that feature should be fairly involved. Once the feature makes it into staging environments, they should see it. 

Kevin Cussen (Deactivated): I think the point person should sit down at the sprint review of features that are being contributed back to ensure they meet the spirit of the Product Committee decision. Essentially as an additional product owner for that particular feature.

For the last 5 minutes, Kevin gave a summary of guidance note and website re-architecture (for openlmis.org). Kevin Cussen (Deactivated) & Tenly Snow (Deactivated) will develope a guidance note and share with the Committees in the next few weeks. 

DECISIONS MADE

Rotating point person is responsible for vetting particular features, rotates after each feature is brought to the Product Committee. Kevin is first. When they are tapped for investigation, that person should document the feature for the committee and provide reasons for and against. Committee can decide to do an ad hoc meeting or not based on input. 

Adding items to the backlog is a simple high/medium/low vote from each product committee member, go with average

Decision to augment teams will be considered on a case-by-case basis

Each point person is responsible for arranging check-ins on their projects (i.e. sprint reviews) and summarizing discussions for the Product Committee

RECORDING

(Bug with Webex - Did not record)

ADDITIONAL READING