Structure of project boards and labels

[MiroDudik]

The current organization of issues and the (lack of) the current organization of PRs make it hard to:

• identify the themes pursued in the package short-term
• identify opportunities to contribute
• tell if somebody is already working to address a specific issue

On this issue, I'd like to brainstorm the right structure for project boards / labels. I think that together with @romanlutz , we will play a bit with the project boards and keep this issue open until we reach a bit of stability.

Some ideas:

If there is an obvious set of items / tasks that comes up within an issue or a proposal, then it's probably not too much overhead to create more granular issues and tag them as "high-priority" (if that's the case) and/or "help wanted"--and put them in the same project as the proposal. We probably shouldn't mark "TODOs" in the proposal and instead just rely on issues (that was my mistake...). If there ends up being a single issue attached to implementation of a proposal, I think that Kevin's suggestion might be easily done by presenting the most up-to-date TODO list at the bottom of the issue--this could be the same comment that's re-edited, or simply the latest comment.

That said--I don't want to force the author of an issue / proposal to split it into smaller tasks if that presents an overhead. I'd rather postpone splitting until there's somebody who wants to help and let them figure it out with whoever submitted the issue (or maybe somebody like the "project owner" if we end up having those).

I feel similar about having a "high-level" issue tagged as "epic" in a project--I'm not opposed, but also don't want to force it, for fear of creating additional overhead.

My current preference is to experiment with project boards and labels. This will help us manage the workflow and ever-so-slightly help with the "discoverability" of the more granular tasks in support of the already planned work.

The project boards should complement the "Short-term roadmap". I like the approach suggested by @kevinrobinson in #500 -- if we use the (short-term?) roadmap to describe the real-world problems we're trying to address (both short-term and long-term), the contributors will be able to come up with issues and/or projects themselves and we will have an easier time identifying the "high-priority" issues. I'm not yet sure if we should use these "problems" as "projects" in our project boards... I think we'll need to experiment a bit.

Originally posted by @MiroDudik in #500

[romanlutz]

I feel like this is a bit backwards. In 90% of the cases people don’t know that there’s something they can help with unless the issue owners say so. That’s why we have to be proactive about marking things as “help wanted” before anyone even asks.

As for the task lists: issues are threads so posting at the bottom gets tedious. That also means it changes through the thread. Task lists are built to be updatable. The project mgmt tool might allow notes on the board with the full list as well, but so far I’ve found it to be too much overhead to use. From what I’ve heard from people they look at issues so that’s probably the best place.

Having separate boards per workstream might work.

[romanlutz]

Switched to using projects instead of milestones now and deleted all milestones. The projects are at the repo level to make sure they're visible. I also tagged a few items as "help wanted". There will be some documentation-follow-up-PR to make sure this is captured in the contributor guide. The main remaining question is whether this is helpful and clear to contributors.

[adrinjalali]

You could also see here how other projects do "up for grab" https://up-for-grabs.net/#/

I find milestones really good for the releases. Project boards work only as long as people maintain them, which can be quite a bit of work. Let's see if they work here :)

[romanlutz]

I had not heard of this! Just submitted the PR for Fairlearn. Thanks a lot for pointing it out @adrinjalali !

I absolutely agree w.r.t. maintaining the boards. I think we'll need "owners" for them that check them at least once a week. I've kind of been keeping track of all issues and PRs even without the boards, so it's not too much extra work. Shall we just start with me managing these or does anyone else want to manage any individual ones? [This is only about keeping the board up to date, no privileges :-) ]

Adding @MiroDudik @riedgar-ms

[adrinjalali]

I think you need to have admin rights to maintain the boards IIRC.

[romanlutz]

How do people feel about this so far? I don't think anyone's looking at the project boards and I've honestly not been able to consistently keep it up to date. I do like it as a grouping mechanism, but that could just as well achieved through labels.

[adrinjalali]

maintaining a board requires a dedicated person to maintain that board. I personally haven't been able to maintain one.

[romanlutz]

Exactly. I don't think it's helping anyone either. For several months I did put in an effort to keep it up to date, but I never once heard that anyone actually uses it. My vote is to switch to just using labels. We can add a few new ones if people like that, such as

• organization/administrative
• visualizations
• metrics
• mitigations
• use-case

@fairlearn/fairlearn-maintainers wdyt?

[hildeweerts]

Good point, @romanlutz! If at some point we have a very specific project with a particular timeline for which a board may be useful we can always reinstate it.

I don't have a strong opinion on specific label names, the ones you mention make sense to me. Maybe use case -> educational materials (or add another one for educational materials). but I'm fine either way.