Wait, hold on a minute. Is the deadline of June because Friday.app is shutting down and we’re worried the sprint checklist won’t be available?
…We use Monday, not Friday.app. I don’t think we use Friday.app for anything, unless I missed some big change?
Oh! I forgot that we did have a UX for it already. Though, we don’t for authoring-- however this is less of an immediate concern if we just want to run checklists. We will need to add in implementation for conditional tasks in any case.
@Fox Just to make sure we’re on the same page - by “authoring”, do you mean the ability for users to create new checklist templates? If so, perhaps I can tackle this (and perhaps the page that lists checklist templates) in the next round of wireframes.
It’s not for our sprints, but for the Open edX Core Contributors sprints :) We use Monday.com at OpenCraft, but I’ve used Friday.app for collecting the Open edX core check-ins. See for example:
and the original thread:
I’ll add you and Ali to Friday.app so you can get an idea (just make sure to disable/delete new check-ins you create, so it doesn’t end up spamming everyone :) ).
(and yes we don’t need authoring – since I manage the core contributors sprints, I can be the one changing manually a config file or source code even, if needed.)
Ahhh! Well, alright, then. I’ll take a look at the invite you sent and see if there are any curveballs we need to consider in the implementation, then.
Yes, though, as mentioned by @antoviaque , other aspects of the app should be focused on first, since we can always use the Django admin for creating the templates in the meantime, and we’ll only need a few of them for our internal cases to start.
@Fox Sorry for the delayed response, I only got around to looking into this in more detail today.
That should definitely be doable 
I made a pass over the capacity allocations for May and there’s a few client-related items that we’ll need to update based on input from epic owners (pinged them in the epic planning spreadsheet). Once that’s done we’ll have a better idea of the number of hours that will be available.
It’s probably worth noting that I’m only looking at this from the perspective of capacity planning for Bebop. Since @Ali is in Deathstar her hours aren’t part of Bebop’s monthly availability; it would be up to her to let us know how many hours she could dedicate to Listaflow, based on her other commitments 
Assuming that the total monthly budget that we’d be willing to spend is still 240h (?), it doesn’t look like Bebop would have room to spend all of it in May. (June might be a different story.)
However, based on my current (= very rough) estimates for capacity needs of the client projects that don’t have allocations set yet, something like 120-160h might be possible for Listaflow in May. This is assuming that Bebop wouldn’t be spending substantial hours on the other accelerated epics in May.
From a design point of view, I don’t see why we couldn’t move the Sprint Planning & Retro Checkins to Listaflow.
I screenshot the 4 components used in the friday.app Core Contributor checkins and added them below for easy reference (the Listaflow design currently only supports checklist items). @antoviaque Just to make sure we’re on the same page, is this what you have in mind:
Emoji select
Numeric rating
Open-ended response
Send kudos
Thanks @tikr. I’ll need to sit down and figure out my availability. I could also get Cassie’s help on the design, but I know she has a lot to do on the Open edX Theme, so I’m not sure that’ll be possible. I’ll wait to hear if my understanding of Xavier’s request is correct, and then will try to figure out my schedule.
Is there some way of knowing which projects take priority over others?
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?
Yes, I’ll have this plan ready by Thursday. CC @farhaan @tikr – I may you guys’ help on the planning there. I’ve created Log in - OpenCraft
Great, thanks for confirming. I’ll probably rope @cassie in as well to get the design to the developers in time.
I will get to work on the UX and UI design for this as soon as @Fox @tikr and @farhaan have finished the planning.
@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.
Current sprint (April 19-May 3): This sprint we are getting the basic checklist functionality and templating done: [BB-5667] Listaflow: Stylize and Make Functional Checklists (#26) · Issues · opencraft / dev / Listaflow · GitLab and @Ali is working on the UI/UX updates for the new fields that will be added.
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.
Next sprint (May 3-17): With UI in hand, we will complete [BB-6160] Add freeform responses and rating fields (#28) · Issues · opencraft / dev / Listaflow · GitLab and get users set up with [BB-5666] Listaflow: Custom user and Social Authentication (#25) · Issues · opencraft / dev / Listaflow · GitLab
We will also get Log in - OpenCraft in to make sure we can have checklist runs on intervals with email reminders. Gabor will finish his prep work.
Sprint after that (May 17-May 31): We set up the Kubernetes deployment for Listaflow and get it out the door, building atop the work Gabor has done. At this point, we should be ready to onboard the Core Committers and start running the checklists through Listaflow and get real feedback!
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 This plan works for me. I’ve shuffled stuff around next week so that I can get the UX/UI ready in time for development.
@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).
@Fox How are things going? Could you post an epic update on the current progress?
Also, it could be good to inform the community of that progress in Core Contributor Sprints - Improvement Survey - #24 by antoviaque - Core Contributors - Open edX discussions – maybe give an update there with some screenshots/designs/links to show something nice, and maybe start planning for the migration steps with Dean, who is now managing the checkins collection? I can jump in as needed.
@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.