PC follow up

[Mary Jo Kochendorfer]

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

1. 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)
2. Reviewing and prioritizing Malawi new feature requests.
3. 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.

1. Label OLMIS-3793 to the “quick win” category that developers can pick up in spare time since it is an easy/straight forward ticket.
2. OLMIS-3702 I will try schedule prior to the 3.3 release.
3. OLMIS-3796 needs more research and can be folded into the Gap Analysis project given the needs around notifications (see Notifications – Push Reminders spec).
4. 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]

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:

OLMIS-3794

OLMIS-3702

OLMIS-3793

OLMIS-3796

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]

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...@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_prod...@googlegroups.com <openlmis_prod...@googlegroups.com> on behalf of Ben Leibert <benle...@gmail.com>
Sent: Monday, December 25, 2017 9:10:13 AM
To: OpenLMIS Product Committee
Subject: Re: PC follow up

 

--
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_co...@googlegroups.com.
To post to this group, send email to openlmis_prod...@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 Bowersox-Johnson]

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

[Brandon Bowersox-Johnson]

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.Ko...@OpenLMIS.org>
Date: Thursday, December 21, 2017 at 5:41 PM
To: openlmis_prod...@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

1. 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)
2. Reviewing and prioritizing Malawi new feature requests.
3. 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]

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