Open SallyMcGrath opened 1 month ago
I would have thought there would be a single backlog+prep time limit, rather than separate ones for each?
(Basically I model this as: There's an implicit backlog item every sprint which is "do the prep", but there isn't a fixed proportion of backlog vs prep, so we should treat sum(prep) as a single component of sum(backlog))
I considered this, but then I thought there is this problem with overloading the prep and not leaving enough time for projects. But maybe I'm wrong and the total time not exceeding 20 hours is better.
But in this case the backlog time extraction blocks this, instead of as an improvement on this, and that's a much bigger task that might not happen. What do you think?
I considered this, but then I thought there is this problem with overloading the prep and not leaving enough time for projects. But maybe I'm wrong and the total time not exceeding 20 hours is better.
If we're saying people don't need to spend more than 20 hours a week, I think "all the work we ask them to do" should fit in that time. It feels fine to label things as optional/stretch if we don't think they're required and then not count them.
If prep + projects takes >20 hours, and we think the projects are important, it feels like the solution should be to have less prep that week, or to stretch out the work over more weeks?
But in this case the backlog time extraction blocks this, instead of as an improvement on this, and that's a much bigger task that might not happen. What do you think?
Incremental improvements are good! At a first cut, we could do something like "Assume all backlog items take less than 12 hours" which may not be true, and improve our accuracy as/when we can?
What is the work that needs to be done?
prep
Given a prep view And a time_limit_prep set in hugo.toml or an override time_limit_prep set in the page front matter
When the total time of blocks set on prep exceeds the time limit Then the build should fail And the error should explain too much work has been assigned
GIven a prep view And no time_limit_prep assigned Then the build should not fail
day plan
Given a day plan view And a time_limit_day set in hugo.toml or an override time_limit_day set in the page front matter
When the total time of blocks set on the day plan exceeds the time limit Then the build should fail And the error should explain too much work has been scheduled and the day is too long
GIven a day plan view And no time_limit_prep assigned Then the build should not fail
backlog
Dependent on time being extracted from issues, which does not yet exist, so possibly this could be done separately
Given a backlog view And a time_limit_backlog set in hugo.toml or an override time_limit_backlog set in the page front matter
When the total time of issues showing on backlog exceeds the time limit Then the build should fail And the error should explain too much work has been assigned
GIven a backlog view And no time_limit_backlog assigned Then the build should not fail
Note that some backlog items are labelled as stretch, and don't have time allocated to them. If the time allocated section contains the (case-insensitive) string "stretch", we should skip it.
Why is this work important to do?
https://common.codeyourfuture.io/common-theme/front-matter/#time
Time is very important to our learners, as many people are fitting learning around other commitments, including multiple jobs, childcare, and other responsibilities. If we are asking someone to do an activity, we must be clear about how long it will take, so they can find that time.
Additional context
738
Who might need to know about this change?