For the past year or two, the @falcon cell has been focused on Axim’s modular learning work, which has been going really well. However, development is now outpacing the UX & product specs for modular learning; we’ve already had some small gaps between epics and there will likely be longer gaps between epics in the future, perhaps even a break in the modular learning work for weeks or a couple months at some point. So it seems like we should change how Falcon works so that we have some other epic(s)/work for the cell members to take on during those times.
The simplest approach would be to just find a totally new epic (unrelated to modular learning) and start working on that, either after the current epic is done, or in parallel. But there could be other options too.
Let me know your ideas and what you’d like to suggest. Then we can get @jordan , @tikr , and everyone else to keep Falcon in mind when planning who gets new epics etc.
A side discussion: Do we have a hint of what the next “Library Relaunch” project for Axim (or openEdx in general) will be?
As the Library Relaunch was a big success, are we trapped in the fallout of a big project, where finding the next one with the same community buy-in and impact is really hard?
If that’s the case, is there anything we can do as Opencraft to create an environment where such an impactful project can emerge? Like bringing feedback from our big customers, draft some ideas with or product team, etc..
If not, what is blocking the next (big) project? Ideas? Funding? Buy-in?
development is now outpacing the UX & product specs for modular learning
If this is the root cause, I think we have a good business opportunity for our Product/UX team. How can we foster that?
Yes, after the course outline, we will likely tackle an epic(s) involving workflow improvements (logs / change history, better publish workflow, and/or bulk actions). And then after that, and probably after Verawood, would likely be something related to Course Templates (not libraries related but still modular learning). But there will probably be gaps between these projects.
I don’t think so; there’s good support for some of the things that I just listed ^.
I don’t think it’s ideas or buy-in. It’s taking the time to figure out the feature and design it thoughtfully, then implement it in a high quality way. For example, everything flows through the Product Working Group, and there’s only so many different major initiatives they can provide oversight for at one time.
Good point. I hope the current work on the Learning Paths project can help demonstrate that.
I agree with @navin, Falcon can handle more than one epic; we’ve done it before. We can handle an internal epic as @rpenido proposed in Replacing JIRA at OpenCraft.
I think the root cause is that Schema is completely focused on the current epic, and it doesn’t work well or on time in the next epic. If there are other epics after the course outline, isn’t there a way to create an opportunity for our Product/UX team to work on them in parallel? That way, Schema would focus on the current epic while our Product/UX team works on the next one.
Thanks. I’m on leave from tomorrow and also don’t have much context on where or why our team was blocked. If you don’t mind, it would be great if you could raise this with Axim and CC me. I can then follow up or chime in once I’m back.
Alternatively, please share some details and I’ll raise it when I’m back in the office. Thank you.
@falcon@braden I’m reopening this thread to share another round of ideas, as the anticipated major gaps are coming in the near future (ref).
For now, what I see as viable for working on those gaps is @rpenido’s original idea of working in the Replacing Jira project. I posted in that thread with more details. What do you think, guys? Do you have any other ideas?
@antoviaque Yes, the Jira replacement project is giving us a good balance. The new Epic (FAL-4326) has already been activated and needs to be delivered before the Verawood cut. In the meantime, I think we can start planning tasks in the Jira replacement project for when that Epic is finished. @navin What do you think?
We’ll soon be finishing the current Epics in Falcon, and we have the Replacing Jira project, but the situation has changed, so I’m reopening this thread.
@ChrisChV Just to make sure there’s no misunderstanding here: Falcon could still work on the JIRA migration in the coming weeks. Just the tickets would stay in Serenity. That way, time spent would count towards Serenity’s non-billable hours, not Falcon’s. And Serenity’s unused budgets from Q1 would cover it.
That said, to improve sustainability Falcon would still need to find billable work for Q2. That’s where the second option comes in
My suggestion, if picking a WGU epic to move over, would be the Template Block project. It has undergone a good bit of discovery but hasn’t started yet, so switching costs would be minimal.
Bebop does feel short on capacity (or at least quite close), and there are tickets right now that are ready to work on but no-one has had time to pick them up. Can Falcon members simply pick some up if more hours are needed immediately? Or is it more complex than that?
Moving the entire epic would be one option, but another (perhaps less disruptive) approach could be to just farm out the majority of tasks from it to Falcon and keep the epic itself in Bebop.
There’s two things happening for Falcon right now.
The cell’s last batch of projects is ending, so it’ll need additional work to fill its capacity starting soon.
At the same time, Falcon’s sustainability ratio was off target in Q1. So the cell should ideally focus on billable work in the coming weeks and months to improve the ratio1.
In terms of filling capacity, having some specific tickets available to pick up certainly helps in the short term. (Thanks for identifying some and posting about them here!) Falcon would also benefit from taking on some larger projects or chunks of work, though, as that would help keep the cell busy more reliably in the medium/long term.
When it comes to sustainability, any non-billable tickets that Falcon picks up in the short term (e.g. SE-6610, BB-10450, and BB-10510 from your list) should stay in the donating cell, and any billable tickets (e.g. BB-10728) would be transferred over. That would be the ideal scenario from Falcon’s perspective. However, we need to keep in mind that Bebop also needs to improve its sustainability ratio. So right now, the best approach would be:
For Falcon to only take over work from Bebop that (a) is billable and that (b) exceeds Bebop’s current capacity2.
For the corresponding tickets to be transferred over to Falcon.
–
1 Unless we end up changing sustainability targets. 2 Unlike in Q1, Bebop currently has no shortage of billable projects so giving away some work that exceeds the cell’s capacity in the short term shouldn’t have too big of an impact on the cell’s ability to increase its output of billable hours and improve its sustainability ratio in the remaining quarters of the year.
