Page Comparison

...

...

Kevin Cussen (Deactivated) gave a brief review of where what we were 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): Suggest I suggest using the mailing list , for initial discussions and jump on a 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 it 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?

Ashraf Islam (Unlicensed): If we think it's a good feature. Can assist with a developer. 

Kevin Cussen (Deactivated): Should we augment their team 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): Strong Does this committee have strong feelings about adding personelle 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. 

...

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 it a feature in the core, we should have a checklist saying why. Important It's important that it isn't arbritaryan arbitrary process.

Kevin Cussen (Deactivated): Technical 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 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: Rotating One suggestion, we have a rotating point person that is up for reviewing incoming pieces? Assigned at each meeting. Initial 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: That 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 , either and plan to discuss on an upcoming call or defer. 

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

Kevin Cussen (Deactivated): Described how Rich described. knowledge at high level reqs, see the low level reqsI'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): Mix the PC and TC 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 of thisfor what projects are happening and where features are being built? A feature coming in will require a bit of backroundbackground. What countries are interested in the feature? Is anyone else building the feature elsewhere? 

Kevin Cussen (Deactivated): Try this out: 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): Does Good question - also brings up the question does the rotating point person make sense if one of us is working on the project?  Brian Taliesin: For something we're doing "in house", no 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 soemone someone has gotten an item, then it passes to the next person.

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

...

What are the expectations for researching globalness, re-aligning roadmap for a new feature that is being built?

How are decisions made?

How often does that individual (or the entire PC) check in on a project?

How do we verify features?

RECORDING

...

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