Thanks everyone more especially @mogoodrich@mseaton in releasing most of the modules .
We are now remaining with few modules and hopefully/presumably this week we may have fully released and remaining with those less than few
If all goes well , we would like to hit the deadline which is on monday to have finished all these unless we have some on going work . thanks
Regards @sharif
@sharif@mozzy@gliff@tendomart - a number of tickets have been raised in Jira by @mogoodrich and @mksd, and there was at least one issue caught in the current Rwanda upgrade going on right now. I was going to post a detailed talk post about these but I don’t think that’s an organized enough approach. There are a lot of Talk threads, slack messages, and other conversations flying around. It’s hard to keep track of the specific fixes that we wanted to make sure get captured in 2.11.0.
Here’s my proposal: Let’s use Jira to organize ourselves.
I suggest we look through the list of tickets that have “Fix Version Reference Application 2.11.0”, and start by focusing on the ones that are listed as blockers, and do whatever those need (whether it’s some dev work or testing). Then, we focus on the ones that are “Must” priorities.
A number of bugs have been raised through different threads in slack and talk. When this happens, we should (1) make sure they are logged in Jira and assigned the “Fix Version Reference Application 2.11.0” label, and then (2) review the ticket in detail to decide if it is really a high vs lower priority. Anything that could create a patient safety issue or block an end user’s workflow should be given the priority level “Blocker”.
I’m not saying that little/fast-to-fix things need Jira tickets necessarily. It’s okay to use our judgement there. But all general or specific to-do’s that need some thoughtfulness should really be captured.
Happy to discuss further! The PM call on Monday might be a great forum for further discussion about this.
Thanks @grace, this seems like the right approach.
First thing I’d recommend doing is looking through the “Blocker” and “Must” tickets in your query and determine which really are blockers/must… looks like some of the recently-added blockers are there, but there are some old things as well that probably could be “Shoulds”.
(Also, for what it’s worth, there are no tickets I’ve specifically discovered and am championing as blockers/musts)
Mark you read my mind, but I didn’t have the guts on a Friday afternoon to ask anyone else to do that review - thank you for taking a look!! You’re 100% right that this needs to be done. I’ll go through it and @sharif@mozzy I hope you can help me have a look as well.
Thanks @grace for bringing this, personally am kinda fixed on some tickets currently but like you said we should fix these tickets, on side of release, its ok we can postpone releases untill we fix everything
Thanks @grace for the filter , was thinking we could optionally add these to another sprint and invite more devs to work on them ahead of 2.11.0 Release. We could leave them here either.
@tendomart thnks for this catch , i think this should be part of the sprint, i think the sprint does not only involve testing but also working on tickets related to specific sprint. Feel free to collect me if am mistaken
@tendomart YES! I LOVE the idea of putting these into a clear sprint. Very actionable and clear.
Only thing is: We’d need to be absolutely sure that all the tickets we put into that sprint are indeed tickets that we really, really want prioritized for the release. @sharif@tendomart would you like to have a working session together to go through the tickets and identify the ones we would prioritize in such a sprint?
Does 6pm EAT tomorrow (Friday) work for both of you @tendomart@sharif? Or would you prefer 4pm EAT tomorrow?
Also, would it be possible for either of you to share your screen on the call? I can show you how I’d typically prioritize tickets and set up sprints in Jira but it’s way better if one of you can get comfortable with this in Jira as well
4pm EAT could work for me, i also would like to ask @grace@tendomart , would it possible to start another sprint before qa sprint get done. Shall we talk about it tomorrow in more depth
We cannot start another sprint before the Retrospective , and that is Monday 19th , that is why i had preffered to hold this meeting on monday after PM call .
Okay since 4pm EAT is 6am PDT for me, which I’m happy to do but not if it’s not very helpful… let’s connect on Monday after the PM call then, at 7pm EAT during the Design Forum time.
To be clear I wasn’t suggesting we start another sprint while the other one is already going on. Typically PMs would prepare the backlog/issue cue for the next sprint before the next sprint starts.
