There’s no absolute answer on that point. Mostly epic owners work with each other to decide which they think is most pressing, consulting the Epic Planning and Sustainability managers for advice (cc @tikr@farhaan). The epic planning and sustainability managers coordinate this and help figure out how many hours each epic will be allocated each month. Due dates are a big factor-- June’s not that far away. Is there a due date for the Open edX theme?
One more thing I noticed about the core contributor checkins is that they are periodic and recurring. Initially we planned to omit the handling of recurrence and let SprintCraft create checklists for each user, but SprintCraft isn’t intended to track the core committer sprints and it sounds like those would be better served by automatic recurrence.
It also means that these recurrences are to be associated with ‘runs’-- which isn’t a concept we had been thinking about previously but will be integral to collation/analytics. Knowing that a set of checklists was not only based on a template, but for a period that covered ‘last week’ is going to be important for getting ‘last week’s sprint stats.’ Alternatively, it could be that we just slice the checklists by actual times they were filled out, but that causes a problem if someone is late-- their stats would affect the next run inadvertently.
@Ali That’s correct, though we don’t have to match the Friday functionalities and prompts exactly – it’s fine (and probably better!) to do it our own way. We could probably even do just fine at first with simply an open-ended prompt, hard-coded questions/template, and a database export/dump of the responses, as long as I have enough access to make changes myself. If we have time for more, I’d actually prioritize email notifications/pings to the participants who haven’t replied yet, as this is a lengthy part of managing those check-ins (many people don’t fill it unless you chase them :( ).
The rest could be on the roadmap, with more time – the critical bit would be to be able to guarantee to the community a smooth migration to that basic MVP in time, even if the features are improved later. And that also means having enough time to migrate & test ahead, so we should have that MVP ready by the end of May.
Between the accelerated projects, I can help answer priorities differences, when/if there is a conflict. For the current case, I would say that if we have the possibility at all to offer this in time to the Open edX community, this project would have priority over all the other accelerated ones during the coming couple of months, while we work on getting it ready in time, and adjust it to the community feedback. It’s a rare opportunity to get external users to use it and provide feedback, this would be invaluable.
Btw I’ll need to give an answer next week, to allow enough time for migration and discussions. @Fox would you be able to give an answer and a plan to present to the community by the end of next week? Say, Thursday, so I have time to post about it on Friday?
@antoviaque@ali@tikr@farhaan I believe I have a plan to get this out the door in time, and before Friday.app shuts down. This pace is a racing one, but I believe we can do it.
Meanwhile, @gabor will begin working on research for managing terraform config/helm charts for our Kubernetes cluster in DigitalOcean, with the intent of paving the way for Listaflow’s deployment there.
If for some reason the DevOps planning work isn’t ready for this release, we fall back to cloning the deployment method SprintCraft currently uses.
Please let me know if you have any concerns about this plan so I can make adjustments as needed in time for you to present it to the Core Contributors.
@Fox@Ali@tikr Thank you for figuring out a way! :) I’ve just posted about it on the official forums, to involve the rest of the community in the discussion, and take a decision whether we adopt the tool for the core sprints:
You’re welcome to join that thread to contribute to the discussion there, and answer questions if there are some? It would also like be worth posting some details about the plan & the updated design mockups there, for those who won’t come read the full thread here.
@Fox That looks like a solid plan to me. It’s a good idea to schedule the bulk of the development work for Sprint 272 (May 3-16) because that leaves Sprint 273 (May 17-30) as a buffer in case some of the work ends up taking a bit longer
Along the same lines, if the tasks that are currently scheduled for Sprint 272 aren’t blocked on work that’s going on this sprint (?), it might make sense to start working ahead on them soon (if there’s room in the sprint).
@antoviaque
The design is going well. There may be a few small tweaks on the reporting wireframes after @Fox’s next review, but it’s pretty much there. I’m currently busy on the UI design for the CC sprint retrospective stuff.
I was going to post an update on the Open edX forum once the UI for reporting had been done, but I can post a bit of eye-candy before then… or maybe just some wireframes - I’ll see what makes sense.
I finally feel like I’m getting on top of the design side of things, so should have more time for communication with the team.
