Follow up for OLMIS-3397

12 views
Skip to first unread message

Nick Reid

unread,
Dec 6, 2017, 2:52:30 PM12/6/17
to Openlmis Dev Mailing List

How OLMIS-3397 was fixed surprised me. We started this discussion in the Sol Develo showcase, and we decided to follow up on the dev-list - so this conversation can progress more slowly (because discussions in Slack have a habit of getting lost)


Here are the issues I'm aware of with this ticket -- please add issues to this email if there is something I've missed.


(A) Lack of design (and implementation) consistency for modals

There are plenty of areas in OpenLMIS that are inconsistent and design documentation is lacking -- modals are a huge area we are improving. See OLMIS-2592 or OLMIS-3689.


I would have assumed that when design logic is unclear, I'd be contacted directly OR the question would be asked in #ui. I never would have expected that an old comment I made would be used to justify a decision.


Going forward, let's loop in more voices when requirements are unclear.


(B) Bug ticket was left in un-auditable state

As noted in the screen shot below, the reproduction steps for the bug are crossed out, and is replaced with a solution. This makes it hard for someone to audit what the problem was, why the solution was chosen, and how to test that the issue is fixed.


NOTE: We now have bug reporting guidelines (better) documented - we must help each other enforce these guidelines.



-- 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


Paweł Gesek

unread,
Dec 7, 2017, 6:18:59 AM12/7/17
to Openlmis Dev Mailing List, Nick Reid
I would have assumed that when design logic is unclear, I'd be contacted directly OR the question would be asked in #ui. I never would have expected that an old comment I made would be used to justify a decision.

From my understanding it was clear, the team assumed we are removing X buttons. Where they wrong? Do we want to keep the X button?

As noted in the screen shot below, the reproduction steps for the bug are crossed out, and is replaced with a solution. This makes it hard for someone to audit what the problem was, why the solution was chosen, and how to test that the issue is fixed.

Yes we shouldn't be crossing out repro steps. I hope these steps were redone using the cancel button instead of the X button in this case?

Regards,
Paweł

On Wed, Dec 6, 2017 at 8:52 PM, Nick Reid <nick...@villagereach.org> wrote:

How OLMIS-3397 was fixed surprised me. We started this discussion in the Sol Develo showcase, and we decided to follow up on the dev-list - so this conversation can progress more slowly (because discussions in Slack have a habit of getting lost)


Here are the issues I'm aware of with this ticket -- please add issues to this email if there is something I've missed.


(A) Lack of design (and implementation) consistency for modals

There are plenty of areas in OpenLMIS that are inconsistent and design documentation is lacking -- modals are a huge area we are improving. See OLMIS-2592 or OLMIS-3689.


I would have assumed that when design logic is unclear, I'd be contacted directly OR the question would be asked in #ui. I never would have expected that an old comment I made would be used to justify a decision.


Going forward, let's loop in more voices when requirements are unclear.


(B) Bug ticket was left in un-auditable state

As noted in the screen shot below, the reproduction steps for the bug are crossed out, and is replaced with a solution. This makes it hard for someone to audit what the problem was, why the solution was chosen, and how to test that the issue is fixed.


NOTE: We now have bug reporting guidelines (better) documented - we must help each other enforce these guidelines.



-- nick --


Software Developer, Information Systems Group

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY4PR02MB2199B4D112489987814793E794320%40CY4PR02MB2199.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875


On Wed, Dec 6, 2017 at 8:52 PM, Nick Reid <nick...@villagereach.org> wrote:

How OLMIS-3397 was fixed surprised me. We started this discussion in the Sol Develo showcase, and we decided to follow up on the dev-list - so this conversation can progress more slowly (because discussions in Slack have a habit of getting lost)


Here are the issues I'm aware of with this ticket -- please add issues to this email if there is something I've missed.


(A) Lack of design (and implementation) consistency for modals

There are plenty of areas in OpenLMIS that are inconsistent and design documentation is lacking -- modals are a huge area we are improving. See OLMIS-2592 or OLMIS-3689.


I would have assumed that when design logic is unclear, I'd be contacted directly OR the question would be asked in #ui. I never would have expected that an old comment I made would be used to justify a decision.


Going forward, let's loop in more voices when requirements are unclear.


(B) Bug ticket was left in un-auditable state

As noted in the screen shot below, the reproduction steps for the bug are crossed out, and is replaced with a solution. This makes it hard for someone to audit what the problem was, why the solution was chosen, and how to test that the issue is fixed.


NOTE: We now have bug reporting guidelines (better) documented - we must help each other enforce these guidelines.



-- nick --


Software Developer, Information Systems Group

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY4PR02MB2199B4D112489987814793E794320%40CY4PR02MB2199.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

Nick Reid

unread,
Dec 7, 2017, 6:03:32 PM12/7/17
to Paweł Gesek, Openlmis Dev Mailing List

From my understanding it was clear, the team assumed we are removing X buttons. Where they wrong? Do we want to keep the X button?

I have been working on building better consensus around the design of UI components in Balsamiq. Every time I draw a modal, there is the "X" button.


There are plenty of places where there is variation in the UI, and there is no formal documentation with consensus from the community (yet).


This email thread isn't about "right or wrong" -- but really flagging that we need to slow down, and make sure we as a community understand the problem we are solving.


I wouldn't have flagged this ticket it:

- There was a clear explanation of what the root cause of the bug was

- Evidence cited was any type of formal documentation

- Development paused to get community feedback (here or in Slack) on what an appropriate solution would be, if it isn't obvious


This is a great tiny example of this, and one that really doesn't matter.


I think we can all think of other situations when changes were introduced to fix an unclear problem, and those changes created other unexpected problems.


-- 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: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Paweł Gesek <pge...@soldevelo.com>
Sent: Thursday, December 7, 2017 3:18:56 AM
To: Openlmis Dev Mailing List
Cc: Nick Reid
Subject: Re: [openlmis-dev] Follow up for OLMIS-3397
 
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

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

Brandon Bowersox-Johnson

unread,
Dec 7, 2017, 9:49:25 PM12/7/17
to Openlmis Dev Mailing List

Here is my take on how the confusion happened. I think it is an overall process/team issue, not any individual, so here is a quick recap of what happened:

 

  • Mid October: Joanna filed this bug mid-October during regression testing. It had a clear statement of a problem, and no proposed solution (perfectly fine for an initial bug report).
  • The ticket was never groomed by Team ILL (never put on a Grooming page).
  • Nov 22, mid-sprint 41: Sam commented suggesting maybe Team Parrot should pick up this ticket if it can still be reproduced.
  • Joanna did reproduce it, so Nikodem added it to the sprint. The bug at this point still had no proposed solution. It was missing what Nick said below: “community understanding of the problem we are solving”. It sat in the sprint and nobody worked on it for a while.
  • Dec 5: On this single day, the bug quickly went to In Progress, In Review, and to QA, and then to Done all in one day (it’s a small code change). There was a Fisheye review by Team Parrot. Team ILL wasn’t on the review and might not have realized work was happening. On that single day, Team Parrot added the Proposed Solution to remove the “X” into the ticket description. The justification is a reference to a comment from another ticket.
  • Nick immediately flagged that very same day that he did not agreed with the proposed solution. So we flagged it to talk about at showcase and retrospective. It was good to flag this and learn from it to improve our processes.

 

Thinking about the “root causes” of how our process caused this confusion, I see a few things we can improve:

  • Strengthen our bug triage process so we have a clearer step where there is review by Team ILL of the proposed solution.
  • Make sure we have alignment/buy-in about tickets before we add them to sprints and start work.

 

I’m open to any other ideas too. Thanks!

-Brandon

 

 

Paweł wrote:

From my understanding it was clear, the team assumed we are removing X buttons. Where they wrong? Do we want to keep the X button?

 

Nick replied:

I have been working on building better consensus around the design of UI components in Balsamiq. Every time I draw a modal, there is the "X" button. … [snip snip]…

Sebastian Brudziński

unread,
Dec 8, 2017, 4:32:39 AM12/8/17
to openlm...@googlegroups.com

Hello,


I just wanted to mention that team Parrot discussed this briefly on the last retrospective. As an immediate improvement to the transparency of the additional issues that are making it into the sprint, but haven't been on the grooming page (eg. because of a request from Team ILL or by pulling a QuickWin at the end of the sprint), we will be including an info about those newly pulled tickets on the daily Slack report. Of course we can and should continue to improve our process, especially with the tickets that are added in the middle of the sprint.


Best regards,
Sebastian.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

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

--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com

Paweł Gesek

unread,
Dec 8, 2017, 5:39:59 AM12/8/17
to OpenLMIS Dev
I have been working on building better consensus around the design of UI components in Balsamiq. Every time I draw a modal, there is the "X" button.
There are plenty of places where there is variation in the UI, and there is no formal documentation with consensus from the community (yet).

Do we have a place where these patterns that are currently are listed? This is not the first time I am hearing about issues with it not being clear what our current patterns are - perhaps we need to condense them in one place? 

I just wanted to mention that team Parrot discussed this briefly on the last retrospective. As an immediate improvement to the transparency of the additional issues that are making it into the sprint, but haven't been on the grooming page (eg. because of a request from Team ILL or by pulling a QuickWin at the end of the sprint)

I like the idea of putting more emphasis on these tickets that are added to the sprint, since they are often trouble, but you can't escape them.

This email thread isn't about "right or wrong" -- but really flagging that we need to slow down, and make sure we as a community understand the problem we are solving.

Just like to point out that on many occasions recently I've been hearing that Team Parrot is too dependent on Team ILL, both from Brandon and on retrospectives. This is now going the completely different direction, where we want to go to team ILL and discuss every change. If that's what we really want, then yes, this isn't about "right or wrong". If however we want the team to become more independent then this is about figuring whether they were "right or wrong" about their assumptions - not to blame anyone, but to figure out what the communication problem here is and how to solve it. From what I am getting it's the lack of understanding about what is a binding pattern on the UI and what's not, but maybe Nikodem can speak out more on this and why that comment was used as reference for coming up with the solution.

Regards,
Paweł 

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

To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/1D8238C9-0CBC-44B9-9729-EB5BFAE07EB0%40villagereach.org.
For more options, visit https://groups.google.com/d/optout.
--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/99dfc481-02af-2631-04a9-b960a48a4534%40soldevelo.com.

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



--

Paweł Gesek
 Technical Project Manager
pge...@soldevelo.com / +48 690 020 875

Nick Reid

unread,
Dec 8, 2017, 12:42:09 PM12/8/17
to Paweł Gesek, OpenLMIS Dev

This is not the first time I am hearing about issues with it not being clear what our current patterns are - perhaps we need to condense them in one place?


That is supposed to be the UI Styleguide, since it is built into the OpenLMIS-UI. Unfortunately it doesn't have a section about modals...

I like the idea of putting more emphasis on these tickets that are added to the sprint, since they are often trouble, but you can't escape them.

I completely agree with both Sebastian and Pawel on this. It is often not clear when the scope of the sprint is changed (or why). If someone has suggestions about a process to make this more transparent, I'd love to hear it. I feel that when these tickets are added, there is a good reason behind it.

Just like to point out that on many occasions recently I've been hearing that Team Parrot is too dependent on Team ILL,

This is a good point, and I personally think Team Parrot would be more productive if Team ILL can supply direction and get out of the way. We do want to encourage and enable independent processes.

Overall, I think the communication between both teams has gotten remarkably better since "the summer of regressions." 

When I look at this issue, and why I'm bringing it up, is that I don't think the original ticket (OLMIS-3397) was actionable. Fixing bugs is a two step process:
- Identify and frame the problem
- Fix the problem

In OLMIS-3397 there were two separate issues described, which both happened to be related to the same element. Many of our bugs look like this. Some bugs are about features that were intentionally left incomplete.

The real question in my mind is how do we as a community build consensus around "bugs" in a timely manner?

Identifying the core issue in a bug, and understanding how it relates to the rest of an increasingly complex software platform is the hardest part. Actually fixing the issue is the easier part (usually).

I also want to mention, our QA process (Joanna) is bringing up bugs in the best possible way — which is quickly and verbosely. 

Some development teams have a QA process that is responsible for diagnosing the issue. We are not staffed to support this (and might never be staffed to support this).

What process steps do we need here? Could we:
- Have a bug triage meeting that moves bugs from Roadmap to ToDo?
- Make the output of a bug ticket to be a task to fix the issue?
- Use service desk to collect "bugs," and only move them into JIRA after triaging the bugs?

- Require a "cooling" period of 48 hours on a bug ticket, between diagnosis and development - which would allow time for feedback?


Overall, thanks for being responsive to this thread. I know we can get this process to work.


❤znick

-- 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


Sent: Friday, December 8, 2017 2:39:55 AM
To: OpenLMIS Dev

Subject: Re: [openlmis-dev] Follow up for OLMIS-3397
 
I have been working on building better consensus around the design of UI components in Balsamiq. Every time I draw a modal, there is the "X" button.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

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

Nikodem Graczewski

unread,
Dec 12, 2017, 7:57:42 AM12/12/17
to Nick Reid, Paweł Gesek, OpenLMIS Dev
Hello everyone,

the reason this ticket was completed the way it was was that I was under the impression that we're going away from the X button. Me and the team decided that it would be unnecessary slow down to ask about such small issue, so, based on our knowledge (how we solved very similar issue and lack of official documentation), we made a call to simply fix it this way.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer

On Fri, Dec 8, 2017 at 6:42 PM, Nick Reid <nick...@villagereach.org> wrote:

This is not the first time I am hearing about issues with it not being clear what our current patterns are - perhaps we need to condense them in one place?

That is supposed to be the UI Styleguide, since it is built into the OpenLMIS-UI. Unfortunately it doesn't have a section about modals...

I like the idea of putting more emphasis on these tickets that are added to the sprint, since they are often trouble, but you can't escape them.

I completely agree with both Sebastian and Pawel on this. It is often not clear when the scope of the sprint is changed (or why). If someone has suggestions about a process to make this more transparent, I'd love to hear it. I feel that when these tickets are added, there is a good reason behind it.

Just like to point out that on many occasions recently I've been hearing that Team Parrot is too dependent on Team ILL,

This is a good point, and I personally think Team Parrot would be more productive if Team ILL can supply direction and get out of the way. We do want to encourage and enable independent processes.

Overall, I think the communication between both teams has gotten remarkably better since "the summer of regressions." 

When I look at this issue, and why I'm bringing it up, is that I don't think the original ticket (OLMIS-3397) was actionable. Fixing bugs is a two step process:
- Identify and frame the problem
- Fix the problem

In OLMIS-3397 there were two separate issues described, which both happened to be related to the same element. Many of our bugs look like this. Some bugs are about features that were intentionally left incomplete.

The real question in my mind is how do we as a community build consensus around "bugs" in a timely manner?

Identifying the core issue in a bug, and understanding how it relates to the rest of an increasingly complex software platform is the hardest part. Actually fixing the issue is the easier part (usually).

I also want to mention, our QA process (Joanna) is bringing up bugs in the best possible way — which is quickly and verbosely. 

Some development teams have a QA process that is responsible for diagnosing the issue. We are not staffed to support this (and might never be staffed to support this).

What process steps do we need here? Could we:
- Have a bug triage meeting that moves bugs from Roadmap to ToDo?
- Make the output of a bug ticket to be a task to fix the issue?
- Use service desk to collect "bugs," and only move them into JIRA after triaging the bugs?

- Require a "cooling" period of 48 hours on a bug ticket, between diagnosis and development - which would allow time for feedback?


Overall, thanks for being responsive to this thread. I know we can get this process to work.


❤znick

-- nick --


--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY4PR02MB2199B3D574CE972348519D1094300%40CY4PR02MB2199.namprd02.prod.outlook.com.

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

Brandon Bowersox-Johnson

unread,
Dec 12, 2017, 12:26:42 PM12/12/17
to OpenLMIS Dev

Hi Nikodem,

 

Your description makes sense to me. I see what happened and why. The fact that we ended up confused or in disagreement at the end is not anybody’s fault. Nick suggested some ways to improve our process, and I think one additional suggestion is that we add Modals into our UI Styleguide. This would give us all a chance to agree on what modal patterns our UI should follow.

 

Nick’s other suggestions (below) are great too. They all involve how we have a clearer step between a Bug Report (documenting the steps to reproduce) versus a Task/Bug-Fix where we identify the proposed solution. Having the extra step or having a 48-hour “cooling period” as Nick suggests, would give us a chance to get feedback and agreement.

 

Also, I agree with what Paweł says about how discussing every single change goes in the wrong direction making Team Parrot dependent on Team ILL. We have to be careful that we don’t put in too much heavy process or delay. It is a balance.

 

-Brandon

 

From: <openlm...@googlegroups.com> on behalf of Nikodem Graczewski <ngrac...@soldevelo.com>
Date: Tuesday, December 12, 2017 at 7:57 AM
To: Nick Reid <nick...@villagereach.org>
Cc: Paweł Gesek <pge...@soldevelo.com>, OpenLMIS Dev <openlm...@googlegroups.com>
Subject: Re: [openlmis-dev] Follow up for OLMIS-3397

 

Hello everyone,

Nick Reid | nick...@villagereach.org

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.


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



 

--

Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.


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



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--

You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.


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

Nikodem Graczewski

unread,
Dec 12, 2017, 8:18:48 PM12/12/17
to Brandon Bowersox-Johnson, OpenLMIS Dev
Hi Brandon,

I think that adding modals into our styleguide would make the difference. We should also identify any other elements that might lack styleguide, but nothing comes to my mind at the moment.

The cooling period like a good idea as long as the ticket would really spend that time under discussion - something we will have to make sure is happening.

Best regards,
Nikodem

Nikodem Graczewski
Software Developer

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

--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

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


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



 

--

Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

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

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

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


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



SolDevelo Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

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

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/406555AB-F832-4C87-B91A-6066682E3929%40villagereach.org.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages