Internal board management process

[rinkug]

Current process

1. Issues in backlog: Every new issue, issues that are not under development but are being tracked for various reasons (for ex: issues that are (1) interesting but no resources available, (2) important but need discussion, (3) broader questions etc.)
2. Selected issues move to "selected for development" i.e when we have time
3. Issues then move to "in progress" if they are being actively worked on
4. Issues move to "done" when completed.

Members routinely go through different columns and issues on a bi-weekly basis and look at issues. Some EB members clean and maintain the board to ensure right labels are indicated and that there are no duplicate issues.

[markcmiller86]

There are a few other aspects to this process that happen before these steps worth mentioning I think...

• BSSw.io editors (and others) routinely identify useful work to do. These are entered as new issues by anyone with the expectation that at some future point, the submitted issue will be reviewed and prioritized relative to other issues. We feel free to add issues with wreckless abandon because a) we believe our downstream processes will probably handle them and b) we don't want to loose track of a good idea.
• A GitHub action currently takes any new issue with the site:internal label and adds it to he Backlog column of the BSSw Internal board.
• We alternate weekly meetings doing content hack-a-thons and operations. So, at a cadence of every other week (but if we have things in which we all tend to participate like ATPESC or Supercomputing or SIAM, we can have a week or two where we cancel operations), we expect to have a one hour meeting where we review new issues and decide what to do with them.
• Our current options with what to do with an item is to a) leave it on the Backlog, b) remove it from the board (in which case we feel strongly it will be lost on the heap of hundreds of other issues in the tracker) or c) move it forward for assignment of resources and work.
• If we have ~20 new items when an operations meeting begins, we cannot take more than 3 mins per item to get through the whole backlog. However, we routinely take much more than 3 minutes on an item. So, what thinking cap are we wearing when we begin an operations meeting and review new items?

[markcmiller86]

@rinkug I believe you also mentioned that you wind up routinely having to engage (or feeling like you need to engage) in reviewing all the open issues. It would be worth including some bullets on that part of the process somewhere here too.

[bernhold]

Slightly off topic, but maybe relevant to our thinking: I figured out how to search for issues that are not on either of our boards:

https://github.com/betterscientificsoftware/bssw.io/issues?q=is%3Aissue+is%3Aopen+-project%3Abetterscientificsoftware%2Fbssw.io%2F2+-project%3Abetterscientificsoftware%2Fbssw.io%2F3+

Our two boards are number 2 and 3. And the leading - on the terms is negation.

[bernhold]

I would amend Rinku's description slightly...

Current process

1. Issues in backlog: Every new issue, issues that are not under development but are being tracked for various reasons (for ex: issues that are (1) interesting but no resources available, (2) important but need discussion, (3) broader questions etc.)
2. Selected issues move to "selected for development" i.e when we have time or when they are important/urgent to address
3. Issues then move to "in progress" if they are being actively worked on
4. Issues move to "done" when completed.

Some of the site:internal issues I add are things that arise, for example, from our discussions with Sandbox/Parallactic and need our input/guidance/decisions. They go straight into Selected for Development if appropriate.

[bernhold]

I would also not say that we go through the backlog every two weeks. As Mark points out, we have an operational meeting every two weeks if we're lucky. And in many cases those sessions are focused on discussions of particular tickets. Which I think it important to helping move things forward. I would say that we look at the backlog pretty rarely, actually. Which might be part of the problem.

As Mark points out, reviewing the backlog becomes a challenge because of the sheer number of tickets there. We can't afford to page the backlog out and back in again with any frequency. I think we need to have a triage methodology that looks at these tickets initially and classify them in more detail so that we can come back later when we're looking for new things to work on, and we can immediately identify a small number of candidates to look at more deeply and decide what to move to Ready for Development.

[markcmiller86]

I would say that we look at the backlog pretty rarely, actually.

I agree that completing review of ALL new stuff added to backlog by GH action is actually rare. We might need to identify a new thinking cap to wear for that part of the process.

But, our options and process for what to do with items in backlog that we review I think is potentially also part of the problem. We've all variously proposed what to do about that (add some labels, take off board, keep tracking it, etc.)

Looking more closely at the 3 reasons @rinkug offers for issues being tracked...

• interesting but no resources available
• important but need discussion
• broader questions

I have to admit, I don't think I am totally clear what these mean and how they are different from each other, especially the 2nd and 3rd bullets.

First, what does "being tracked" mean? Its in our issue tracker. By that definition, its already "being tracked". Well, that isn't quite fair because, unfortunately or not, our tracker is a big bucket of stuff and so anything that goes into it we live in fear it might get lost. But, if we feel that way about everything in there, we're in trouble because we have no way to differentiate the stuff we care most about from the stuff we care least about (or perhaps put another way, would only do if we had unbounded resources)

Next, what do the descriptors "interesting" and "important" mean? Interesting to who? Important to who? For each issue, do all EB members agree on these attributes of any given issue? When is such agreement made? I think this may be some of what needs to happen in a triage step. Prior to triage, nothing is interesting or imporant or at least no more so than any other new issue since last traige.

Finally, we might have a lot of things that are important and a lot of things that are interesting. But, we have highly constrained resources and I think we all agree we would like to optimize the use of those resources to work on the things that we believe will yield the highest return on investment. And, we'd also like to ensure that the resources we spend managing the llist of things to do is small relative to actually doing any of those things.

But, here too, we may have some challenges because there are individual goals/values (as well as highly variable individual expertises -- which represents the kinds of tasks each of us is most productive with) and group goals/values and sometimes those are not always fully aligned. This means not only is the amount of resource we have available heavily constrained but also the kinds of tasks resources can be applied to. For example, maybe I am most inspired by activities that relate to inclusion in some ways whereas maybe @bernhold has the most expertise amoung us at adjusting BSSw.io CI stuff.

We also know its a big productivity hit to constantly revist and refamiliarize ourselves with all the issues we're "tracking" to go find the next best thing to work on.

As an aside, I am thinking about In-N-Out Burger again...from the perspective of a food consumer instead of food producer this time. It takes me < 10 seconds to select an item from an In-N-Out Burger menu whereas it takes many minutes from TGI Fridays menu :wink:

[rinkug]

@bernhold : lets decide what to do with this issue? Close it? Leave it open with the future plan?

[bernhold]

I think maybe we could close this now, in the interest of trying to reduce the number of open issues as we transition into a new operational phase for BSSw.io.