regarding the sprint planning meeting: It is scheduled for 11 AM PDT, which is 6PM UTC on March 21, one hour after the standup time, due to the code review session happening just before then.
For those who have not attended such a meeting before, the main purpose is to agree on the list of tasks we’ll try to tackle during a two week period, including relative prioritization. It is not a task assignment meeting – tasks are self-assigned by developers during the course of the sprint.
This “we” need not be exclusive to paid full-time developers at all. I’m very open to us having explicit tradeoff conversations about predictability. For instance, if we have a task “clean up docs on such and such”, and we determine that some risk of non-completion is okay on that task, I see no problem with a volunteer who is uncertain about their availability participating via the sprint + daily standup model. If that task just doesn’t get done at the end of the sprint, that’s totally fine.
The importance IMO is for us to be intentional about this stuff, to make tradeoffs explicit, and to adapt methods to our needs, not the other way around.
In that spirit, I would suggest that volunteers who can make the time (I know it’s inconvenient for many) try to listen in and participate as they see fit. But note that we also have the Thursday 30 minute meeting (our regular weekly engineering meeting) to go over other non-sprint issues, such reviewing IFF results + discussing UX interviews.
Thanks for suggesting the sprint review as another option to drop in. We haven’t yet decided whether we’ll do a review for this sprint. My sense is that if the sprint is going to be mostly focused on post 0.6 fixes, backend changes, and pending PRs, we probably won’t need to do a formal showcase. We may also choose to use one of our pre-existing practices (such as the code review sessions we’re doing every other week) to dive into a particular change.
I suspect the new SecureDrop website, however, might benefit from this kind of broad review. Similarly, some of the kinds of UX changes we’ve discussed would definitely benefit from a group review. Let’s kick this around a bit and we can set something up at the appropriate time.