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
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.
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.
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.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
--
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
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.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
--
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
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
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:
Thinking about the “root causes” of how our process caused this confusion, I see a few things we can improve:
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]…
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.
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
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).
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)
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.
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.
Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875
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 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.
Just like to point out that on many occasions recently I've been hearing that Team Parrot is too dependent on Team ILL,
- 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
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.
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.reid@villagereach.org
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CADt-Nu0UGBb2V7aW_fqjA58nL-KTCrk5Cc%3D5sz%2BffKea4myabg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
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.
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...@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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CADt-Nu0UGBb2V7aW_fqjA58nL-KTCrk5Cc%3D5sz%2BffKea4myabg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
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.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW7EH6pWEiqam1cfHz9pcW6ccgkmhwfWxUf_JjB_M6Xrg%40mail.gmail.com.
Nick Reid | nick.reid@villagereach.org
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.
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/CADt-Nu0UGBb2V7aW_fqjA58nL-KTCrk5Cc%3D5sz%2BffKea4myabg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
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 view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAGOM9mW7EH6pWEiqam1cfHz9pcW6ccgkmhwfWxUf_JjB_M6Xrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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.