<div dir="ltr">Hi again!<div><br></div><div>To follow up on the discussion yesterday, I have spend quite a bit of time going through everything that was tagged against 2022-related milestones and somewhat heavy-handedly changed things a bit.</div><div><br></div><div>1) First, I&#39;ve tried to improve our usage of milestones. All active milestones now have both clear start and end dates, and I have created distinct milestones for items such as beta2, the release candidate, and actual release. At the same time, I have also created all the milestones for release-2023 to make future planning easier.</div><div><br></div><div>2) However, in contrast to our earlier setup, we should be much more restrictive with wadding issues to milestones. As I see it, these milestones should be reasonably well-planned intervals of a few weeks to a few months, and when we add an issue to a milestone that should correspond to deliberate planning that we&#39;ve decided to prioritize it, there are efforts allocated, and a fairly serious expectation we&#39;ll be able to finish it - and actually *close* the issue - by the milestone.</div><div><br></div><div>3) We will of course occasionally miss milestones, which is fine, but there is little to no utility in unrealistically having hundreds of issues marked for a milestone just to end up bumping 90% of them to the next milestone when the date finally comes. Second, I think we&#39;ve repeatedly created situations where we&#39;re incapable of making proper planning/priorities because there are hundreds of active issues for a particular target.  So, my thought here is that by being much more restrictive about things we actually target for a milestone, we will be able to do a better job at prioritizing (and finishing) the things we do list.</div><div><br></div><div>4) For the current release phase, I think we all agree that we both want a few remaining code fixes in, we want to shepherd important things already submitted into the release, and do testing. To be able to achieve that and ship a beta2 that is at least code-complete by November 26, we need to accept that we only have ~10 more days to submit actual new code, after which we need to reserve ~10 days for code review and a final few days for testing.  Thus: A milestone of e.g. Nov 26 is a joint milestone for us as a _team_ to finish everything for beta2, not an indication we can all keep working on new code that we submit on November 25 :-)</div><div><br></div><div>5) Finally, I want to attempt a slightly &quot;tighter&quot; (in lack of better words) beta cycle where we don&#39;t overwork the team, do hail-mary coding/testing over the holidays or push things into January. If we are successful at that, perhaps we could consider modifying our schedules into having a major patch (or new release) after 6 months, which would remove the issue where we are all a bit overworked this time because it&#39;s the last chance to get stuff in for a year. No promises, but it&#39;s worth a shot.</div><div><br></div><div><br></div><div>So, based on all this I would ask everyone to:</div><div><br></div><div>A) Go through open issues and bug reports not yet targeted for 2022.beta2 and help us find ones that are so important that we really *should* prioritize them over others in the next ~10 days.</div><div><br></div><div>B) Help with open issues targeted for 2022.beta2, and/or split large such issues into smaller components if necessary. Perhaps there is one part that can make it into release-2022, while we push others to next year?</div><div><br></div><div>C) Be realistic about priorities. You&#39;re all doing a GREAT job, and almost all issues are worthwhile, it&#39;s just that we have to decide which ones are more important than others at this point, and make sure we focus on those. Deciding to push some things is not failure, but good team-work!</div><div><br></div><div>D) Help reviewing each other&#39;s changes! Towards the end of this month we&#39;ll get a bit more formal about this and try to assign people to help with reviews, while we mostly stop considering new code changes.</div><div><br></div><div>E) Be gentle &amp; collaborative in comments and code review. We will need to make exceptions, we will need to accept code that might not be perfect - and we will also need to decide that some changes simply don&#39;t make the release in time. These decisions will not be perfect or 100% fair, but the better we are at quickly making decisions about such cases, the more time we will have to help each other with review and maybe making one more exception. </div><div><br></div><div><br></div><div>All the best,</div><div><br></div><div>Erik</div><div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div><div><br></div><div>Note: I frequently do email outside office hours because it is a convenient time for me to write, but please do not interpret that as an expectation for you to respond outside your work hours.<br></div></div></div></div></div></div></div></div></div></div></div>