PC follow up

Mary_Jo_K · December 22, 2017, 1:41am

Hello PC,

After the
Product Committee on the 19^th, there were three things we said we’d follow up on email. I know the following is a bit dense, please do review and respond to this email with comments. I will be out of office until Jan 10^th so make sure to respond to the listserv so Sam and others can field/incorporate your comments.

Topics to follow up on

···

Update on the decision for how to address issues related to sending data from the report and requisition into stock cards (within the stock management service)
Reviewing and prioritizing Malawi new feature requests.
Approach to redesign emergency requisitions.

Number 1: First, we understand it is challenging to understand the details raised around the current challenge with connecting the services (outlined
here). As a recap, the problem is when Report and Requisitions (R&R) are approved out of order (upon approval the stocking information is sent to stock cards as a physical inventory). Our phased approach to solve this issue is to move forward with option 1B (Allow Physical Inventory without requiring reasons for the entire quantity change) first and then begin work to support the reversal functionality. We recommend implementers to monitor reporting rates and encourage users to approve R&Rs in order. I know this entire scenario is challenging to follow. Please do not hesitate to reach out with questions or comments. We can continue to discuss this during the next product committee meeting.

Number 2: Following up from the PC meeting, I am requesting folks to review the tickets and let me know if you think these are project specific and not globally applicable. From my review, I believe OLMIS-3793 and 3702 are globally applicable and would bring value to the core. I believe OLMIS-3796 and OLMIS-3794 need a bit more refinement and information before determining if they are globally applicable. I WELCOME input from others so that we have input from a wide variety of members.

In addition, could someone on the Malawi team please review the list of requests and provide information on the following:

Are there any time sensitives around these requests?
Is there bandwidth on the Malawi team to work on these and submit a pull request?
Are the current priorities accurately reflecting your priorities? Currently OLMIS-3794 is critical.
If possible, please update the descriptions of the ticket to highlight the end user value. I created a user story for OLMIS-3702 which I’d like review of to ensure I captured the need/value

What next? Currently most resources are out on holidays. In the new year, we need to prioritize these requests. Currently I believe they will fall into the following based on level of effort, priority and resources.

Label OLMIS-3793 to the “quick win” category that developers can pick up in spare time since it is an easy/straight forward ticket.
OLMIS-3702 I will try schedule prior to the 3.3 release.
OLMIS-3796 needs more research and can be folded into the Gap Analysis project given the needs around notifications (see
Notifications – Push Reminders spec).
OLMIS-3794 I left some questions for Nuran.

We can provide an update on the upcoming product committee meeting.

Number 3: Sam will send an update on the current approach next. Please review once it is sent.

Ben_Leibert · December 25, 2017, 5:10pm

Hi everyone,

Merry Christmas – I hope you’re enjoying a wonderful one!

For the most part, I think that the issues (MW-3702, OLMIS-3793, OLMIS-3794, and OLMIS-3796) should be fairly straight-forward for us to implement. I thus prefer that we attempt to, and that we save our reliance on the Core’s development team for matters we’re less equipped to handle.

Even if we do the development work, it’s important for us to know ahead of time that the product committee is amenable to accepting it. This is because the code for a ticket like OLMIS-3793 will be written differently if it’s destined for inclusion in the Core’s codebase. Meanwhile, discussion with the product committee allows us to approach a ticket like OLMIS-3796 in a way that the global community will embrace.

Based partly on work we’ve already done, and upcoming needs I believe we have, I’d personally suggest the following descending-order of precedence:

The OLMIS-3796 ticket is last partly because it needs further definition. The other tickets are currently actionable, though. Do they represent additions which the product committee feels would benefit the Core product?

Kind regards,

Ben

Nick_Reid · December 27, 2017, 6:59pm

Ben -

I’m friendly to all the tickets except
OLMIS-3796, which I agree needs more definition to make sure the feature really meets user needs (example: we support users with no email addresses, how would they be notified of system down time?)

It would be great if you or Nuran Idris would start a new email thread and re-state the problem that OLMIS-3796, hopes to solve.

I think slowing down the development of the group email messaging feature, and working to build consensus within the community would be a great exercise for all of us.

Happy Holidays,

– nick –

···

Nick Reid | nick.reid@villagereach.org

Software Developer, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org

From: openlmis_product_committee@googlegroups.com openlmis_product_committee@googlegroups.com on behalf of Ben Leibert benleibert@gmail.com

Sent: Monday, December 25, 2017 9:10:13 AM

To: OpenLMIS Product Committee

Subject: Re: PC follow up

Hi everyone,

Merry Christmas – I hope you’re enjoying a wonderful one!

For the most part, I think that the issues (MW-3702, OLMIS-3793,
OLMIS-3794, and OLMIS-3796 ) should be fairly straight-forward for us to implement. I thus prefer that we attempt to, and that we save our reliance on the Core’s development team for matters we’re less equipped to handle.

Even if we do the development work, it’s important for us to know ahead of time that the product committee is amenable to accepting it. This is because the code for a ticket like OLMIS-3793 will be written differently if it’s destined for inclusion in the Core’s codebase. Meanwhile, discussion with the product committee allows us to approach a ticket like OLMIS-3796 in a way that the global community will embrace.

Based partly on work we’ve already done, and upcoming needs I believe we have, I’d personally suggest the following descending-order of precedence:

The OLMIS-3796
ticket is last partly because it needs further definition. The other tickets are currently actionable, though. Do they represent additions which the product committee feels would benefit the Core product?

Kind regards,

Ben

–

You received this message because you are subscribed to the Google Groups “OpenLMIS Product Committee” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis_product_committee+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis_product_committee@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis_product_committee/e0b55501-21be-4d2e-b6c2-2c48e9a44aa6%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

brandon · January 8, 2018, 11:06pm

Hi Ben and Product Committee,

It’s been a few weeks so I wanted to jump-start the conversation about the Malawi-requested tickets:

OLMIS-3794 – Nuran has answered Mary Jo’s last question, and I left a new question for Sebastian about the revert/undo. Overall, Mary Jo had said she wanted “more refinement and information before determining if [this is] globally applicable”.

OLMIS-3702 – Lots of questions have been answered in the comments of this ticket. Perhaps Ben could now update the ticket description to reflect all of this and to have Acceptance Criteria. Mary Jo already said this one is globally applicable and will be welcome into core.

OLMIS-3793 – I wrote some suggestions for Ben on how to flesh out this ticket. He let me know that Christine and Nuran are planning to discuss the tickets. Mary Jo also said this one is globally applicable.

OLMIS-3796 – Nuran, did you have any thoughts on Nick’s question below about a fresh explanation of what problem we are trying to solve. The Product Committee discussion offered lots of ideas, tools and alternatives.

-Brandon

···

From: openlmis_product_committee@googlegroups.com on behalf of Nick Reid nick.reid@villagereach.org

Date: Wednesday, December 27, 2017 at 1:59 PM

To: Ben Leibert benleibert@gmail.com, OpenLMIS Product Committee openlmis_product_committee@googlegroups.com

Subject: Re: PC follow up

Ben -

I’m friendly to all the tickets except OLMIS-3796, which I agree needs more definition to make sure the feature really meets user needs (example: we support users with no email addresses, how would they be notified of system down time?)

It would be great if you or Nuran Idris would start a new email thread and re-state the problem that OLMIS-3796, hopes to solve.

I think slowing down the development of the group email messaging feature, and working to build consensus within the community would be a great exercise for all of us.

Happy Holidays,

– nick –

Nick Reid | nick.reid@villagereach.org

Software Developer, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org

From: openlmis_product_committee@googlegroups.com openlmis_product_committee@googlegroups.com on behalf of Ben Leibert benleibert@gmail.com

Sent: Monday, December 25, 2017 9:10:13 AM

To: OpenLMIS Product Committee

Subject: Re: PC follow up

Hi everyone,

Merry Christmas – I hope you’re enjoying a wonderful one!

For the most part, I think that the issues (MW-3702, OLMIS-3793,
OLMIS-3794, and OLMIS-3796 ) should be fairly straight-forward for us to implement. I thus prefer that we attempt to, and that we save our reliance on the Core’s development team for matters we’re less equipped to handle.

Even if we do the development work, it’s important for us to know ahead of time that the product committee is amenable to accepting it. This is because the code for a ticket like OLMIS-3793 will be written differently if it’s destined for inclusion in the Core’s codebase. Meanwhile, discussion with the product committee allows us to approach a ticket like OLMIS-3796 in a way that the global community will embrace.

Based partly on work we’ve already done, and upcoming needs I believe we have, I’d personally suggest the following descending-order of precedence:

The
OLMIS-3796 ticket is last partly because it needs further definition. The other tickets are currently actionable, though. Do they represent additions which the product committee feels would benefit the Core product?

Kind regards,

Ben

brandon · January 12, 2018, 9:36pm

Hi Product Committee,

I also wanted to provide an update on Number 1 below from December’s meeting. Mary Jo stated below that the phased approach for moving forward is starting with Option 1B (Allow Physical Inventory without requiring reasons for the entire quantity change). That is now captured in this ticket:
https://openlmis.atlassian.net/browse/OLMIS-3921 . Feel free to add comments on that ticket or reply if you would like this topic to have some discussion/updates at the next PC meeting.

-Brandon

···

From: Mary Jo Kochendorfer MaryJo.Kochendorfer@OpenLMIS.org

Date: Thursday, December 21, 2017 at 5:41 PM

To: openlmis_product_committee@googlegroups.com

Subject: PC follow up

Hello PC,

After the
Product Committee on the 19^th, there were three things we said we’d follow up on email. I know the following is a bit dense, please do review and respond to this email with comments. I will be out of office until Jan 10^th so make sure to respond to the listserv so Sam and others can field/incorporate your comments.

Topics to follow up on

Update on the decision for how to address issues related to sending data from the report and requisition into stock cards (within the stock management service)
Reviewing and prioritizing Malawi new feature requests.
Approach to redesign emergency requisitions.

Number 1: First, we understand it is challenging to understand the details raised around the current challenge with connecting the services (outlined
here). As a recap, the problem is when Report and Requisitions (R&R) are approved out of order (upon approval the stocking information is sent to stock cards as a physical inventory). Our phased approach to solve this issue is to move forward with option 1B (Allow Physical Inventory without requiring reasons for the entire quantity change) first and then begin work to support the reversal functionality. We recommend implementers to monitor reporting rates and encourage users to approve R&Rs in order. I know this entire scenario is challenging to follow. Please do not hesitate to reach out with questions or comments. We can continue to discuss this during the next product committee meeting.

…(snip snip)…

Nuran_Idris · January 15, 2018, 8:31am

Hi Nick and Brandon;

I have provided some comments directly to the ticket. It will be helpful if there are some specific questions from your end so that i can provide additional information.

Best,

Nuran

···

On Friday, December 22, 2017 at 3:41:26 AM UTC+2, maryjo.kochendorfer wrote:

Hello PC,

After the
Product Committee on the 19^th, there were three things we said we’d follow up on email. I know the following is a bit dense, please do review and respond to this email with comments. I will be out of office until Jan 10^th so make sure to respond to the listserv so Sam and others can field/incorporate your comments.

Topics to follow up on

Update on the decision for how to address issues related to sending data from the report and requisition into stock cards (within the stock management service)

Reviewing and prioritizing Malawi new feature requests.

Approach to redesign emergency requisitions.

Number 1: First, we understand it is challenging to understand the details raised around the current challenge with connecting the services (outlined
here). As a recap, the problem is when Report and Requisitions (R&R) are approved out of order (upon approval the stocking information is sent to stock cards as a physical inventory). Our phased approach to solve this issue is to move forward with option 1B (Allow Physical Inventory without requiring reasons for the entire quantity change) first and then begin work to support the reversal functionality. We recommend implementers to monitor reporting rates and encourage users to approve R&Rs in order. I know this entire scenario is challenging to follow. Please do not hesitate to reach out with questions or comments. We can continue to discuss this during the next product committee meeting.

Number 2: Following up from the PC meeting, I am requesting folks to review the tickets and let me know if you think these are project specific and not globally applicable. From my review, I believe OLMIS-3793 and 3702 are globally applicable and would bring value to the core. I believe OLMIS-3796 and OLMIS-3794 need a bit more refinement and information before determining if they are globally applicable. I WELCOME input from others so that we have input from a wide variety of members.

In addition, could someone on the Malawi team please review the list of requests and provide information on the following:

Are there any time sensitives around these requests?

Is there bandwidth on the Malawi team to work on these and submit a pull request?

Are the current priorities accurately reflecting your priorities? Currently OLMIS-3794 is critical.

If possible, please update the descriptions of the ticket to highlight the end user value. I created a user story for OLMIS-3702 which I’d like review of to ensure I captured the need/value

What next? Currently most resources are out on holidays. In the new year, we need to prioritize these requests. Currently I believe they will fall into the following based on level of effort, priority and resources.

Label OLMIS-3793 to the “quick win” category that developers can pick up in spare time since it is an easy/straight forward ticket.

OLMIS-3702 I will try schedule prior to the 3.3 release.

OLMIS-3796 needs more research and can be folded into the Gap Analysis project given the needs around notifications (see
Notifications – Push Reminders spec).

OLMIS-3794 I left some questions for Nuran.

We can provide an update on the upcoming product committee meeting.

Number 3: Sam will send an update on the current approach next. Please review once it is sent.