<div dir="ltr"><div dir="ltr">Hi,<br><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 27, 2021 at 8:10 PM Eric Irrgang <<a href="mailto:ericirrgang@gmail.com">ericirrgang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
Is there an expectation that we are tracking this flow with Status labels? It is unclear how or why some issues have Status labels and others do not, but it seems like a useful practice if we can clarify how it is supposed to take place.<br></blockquote><div><br></div><div>I don't have any patent answer, I'm afraid. However, given that we are a very diverse & distributed team (which comes with a TON of obvious advantages too), my personal preference would be that we should strive for sufficient documentation/text/status in each issues so that somebody who has not been involved in it before will be able to more or less directly understand what the status is, if anybody is working actively on it, if there's interest (we should get better at using thumbs up/down I think!), or if it's just gone stale because we don't have time.</div><div><br></div><div>I think we're skilled enough to aim for a lot of freedom (since issues are also VERY different in nature), as long as we find a way to avoid going back into exponentially growing complexity :-)</div><div> </div><div>There is one thing I have a bit of bad conscience about, and that's the umbrella vs. child issues. I know they are important, and in principle hierarchical organization is good, it's just that I don't know how to handle the complexity (in terms of sheer open-issue-count) when a bunch of umbrella issues have several dozen children that we aren't working actively on (yet). Maybe one solution could be to just list expected upcoming children in a task-list in the umbrella issue, and hold off creating the actual issues until we at least expect to work on them in the foreseeable future.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Yes. But what is the new mechanism by which we will do a better job of managing the issue life cycle, moving forward? Do some or all of us have a responsibility to apply labels independently? As a group (during biweekly telcos or at quarterly planning meetings)? Do we expect to only close issues that time out to inactivity, or are we actively trying to find a way to close issues in a more considered way?<br></blockquote><div><br></div><div>I would suggest two things: </div><div><br></div><div>* First, I've played around with running gitlab-triage in the CI (interfacing with the database), and I think I found a config that will allow us to automatically label things as "stale" when they haven't had updates e.g. in 2-3 months. My plan is to add a default text apologizing we haven't been able to look into it, provide some trivial suggestions, but then also saying that if this is an umbrella or child issue, it's an indication it's time to provide an update of status, timeplan and assignee(s). Spontaneously, I'm even thinking of auto-closing stale issues that still don't get an update in another 3 months unless somebody is assigned (then we can warn the assignee first(. That might seem harsh, but if we haven't bothered looking at it for a quarter, we don't bother to provide an update when reminded, we don't bother to assign it to anybody, and then let another quarter pass - then I would say that we effectively already voted to close (or at least ignore) it, so the "closed" status is really just reflecting reality.</div><div><br></div><div>* Second, I think the bi-weekly telcos are a great point to spend 10 minutes syncing on the status of issues and decide what has to be accepted/rejected/closed, and make sure we don't have a ton of issues without assignees. The hardest part is likely that we'll have to accept that we can't really have more than ~30 (or whatever issues each assigned. After that it's just a question of whether we are closing old or rejecting new things - but keeping that in mind might help us to jointly prioritize. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
1. Since the issues were closed without labeling them "Status::inactive", it is harder to apply a search filter that distinguishes between conversations on fixed bugs, rejected ideas, or productive conversations that merely stalled out.<br>
* Do we plan to use (increase the use of) Status labels in the future?<br></blockquote><div><br></div><div>Labels (or detailed comments) are awesome, but prio #1 is that we make decisions, so I don't want us to hold back on decision-making/actions because we first carefully want to label each issue with the exact reason :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
* Is there any objection to adding the Status::inactive label to issues that were closed in the recent purge to make it easier to find old discussions, should they become relevant again?<br></blockquote><div><br></div><div>On the contrary, that would be great! </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
2. I don't think anyone would disagree with the comments that you pasted in many issues that it would be useful to have a better indication of timelines and people involved. But, if a lack of such information justifies closing the issue,<br>
* what is the proposal for establishing this information, and<br>
* how should allocated effort and approved timeline be reflected in the issue?<br></blockquote><div><br></div><div>See above; I don't think we want to have _one_ prescribed way it must be done, but the key is that a reader should be able to understand (very roughly!) what the status is by reading the issue rather than having to check with everyone on the team.</div><div><br></div><div>However, one (strong) preference I have is that we make it the responsibility of team members who want to keep an issue open to also ensure that it has reasonably up-to-date information, rather than saying it's the poor soul (often Paul the last 2-3 years...) actually trying to clean up who also gets the unthankful job of reminding people.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> we do have to make tough calls as a project, and every single feature/task that might be nice to have might not be a good priority for the rest of the project to spend time on.<br>
<br>
Absolutely. But it is still not clear to me how and by whom these calls are made, and how/where the decisions are recorded.<br>
<br>
I would think that some combination of the biweekly telco and the quarterly planning meeting would provide a sufficient venue to accept or reject issues, estimate timelines, and gather participants. The quarterly planning meeting would seem like an appropriate venue to accept, refine, or reject large or early-phase proposals.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
In recent quarterly meetings, documentation was requested as "umbrella issues". Unofficially, Milestones describing features or functional levels have been used effectively for several efforts. I think we should strongly consider topical Milestones to focus discussion for larger projects/proposals at planning meetings, where we can collectively set a due date for Milestones that are chosen for targeting in a given development period.<br><br></blockquote><div> </div></div><div>agree on both counts.</div><div><br></div><div>Cheers,</div><div><br></div><div>E.</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & 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>