[RFC] operational notes: tracking yearly goals

[japaric]

this is an RFC to change how we track yearly goals (previously edition goals) to
reduce the amount of triage time during weekly meeting.

TL;DR we go from weekly poll-based triage to (bi)weekly self-reports where we
only discuss issues that are not making progress

[korken89]

I quite like this model, +1 from me overall.

[jamesmunns]

+1 from me as well, I'll wait to see if there are any comments, or feel free to ping for GitHub approval

[therealprof]

The one concern I have is that this contains the implicit assumption that people work like factories and churn out a certain amount of work per week. Most of use are doing WG work voluntarily so I don't think such an assumption holds.

Other than those assumptions/requirements I'm okay with the approach.

[paoloteti]

I have the same concern. I use to work on Rust at home (night or weekends) or as part of my company program that give me few hours per months. But, of course, this just the way I can contribute and the time I can spend. A part of this the overall approach looks good to me.

[andre-richter]

I need to chime in with @therealprof and @paoloteti. I can ever only work when I have free time, I don't have a company program that allows me doing this either.
I would love to do more, but realistically, it will happen that I won't be able to update for weeks, e.g. when there's crunch time at work or big family vacations, etc.

I also think this will very much depend on the composition of the teams. Teams with few people that are purely free-time workers won't probably be able to follow a weekly cadence, whereas in bigger teams this might be less of a problem.

Otherwise, I like the approach! 👍

[japaric]

@therealprof @paoloteti @andre-richter Thanks for raising your concerns

I added the "requirements" because I know members help out in their limited free time. Let me clarify their intention:

• First of all, this is only about tracking. You are not expected to do weekly, or biweekly, or any work on the issues assigned to you. Just checking how / if things are progressing.

• "All tracking issues have at least one team associated to it". This is for visibility and the convenience of the community. If someone has questions about tracking issue, or they want to volunteer to help out, then they should check with the assigned team.

• "All issues will have at least one WG member assigned to it". Note that it says "WG member" rather than "team member" so WG members can track other teams issues. This is to allow a dedicated triage team help out with the tracking.

  • I also meant this to provide "redundancy" (e.g. the assignees can take turns in writing summary reports) but perhaps it should say "at least two".

• "No member shall be assigned to more than three tracking issues at any point in time". This is for load balancing the tracking work across the WG and to limit the number of in-flight issues. If there's not enough people to track issues then likely there's not enough people to mentor or work on them either. If there's not enough people then the goal can stay in "not started" state until people free up.

• ".. post a summary report each week ..", "If (..) the issue hasn't changed since last week the assignee can skip the summary report of that week ..". So report cadence can be as slow as biweekly or even monthly if you pair up with someone to do the tracking.

• "At least one member of the team assigned to the issue must attend that meeting." Perhaps this should be "should" instead of "must". It's best if someone on the assigned team can be present but if they can't -- not everyone can attend weekly meetings due to their schedule -- leaving a status comment somewhere before the meeting can be enough. It depends on the situation too; in some cases we may be able to sort things out without the team involvement (e.g. if blocked on upstream change or RFC anyone can check with rust-lang/rust).

Hopefully that makes things clearer. Could you elaborate on which guidelines you find problematic?

[Disasm]

@japaric, I think these tracking rules still should be made more "socially-comfortable".

First of all, this is only about tracking. You are not expected to do weekly, or biweekly, or any work on the issues assigned to you.

This "you are not expected" part is not obvious part at all. I think, generally people do expect for some work to be done.

"All tracking issues have at least one team associated to it". This is for visibility and the convenience of the community. If someone has questions about tracking issue, or they want to volunteer to help out, then they should check with the assigned team.

Good point, but... useless for now. There should be a obvious way to reach the corresponding team. I wonder if GH can notify all team members when someone comments an issue?

So report cadence can be as slow as biweekly or even monthly if you pair up with someone to do the tracking.

I think there should be an easy way to signal "paused" state for an issue. Such "paused" issues will receive no tracking until resumed or taken by someone else. Same for meetings. I think, tracking comments should describe ongoing problems, but "no progress" situations should not be tracked at all. Maybe such situations should be detected automatically and handled by other team/WG members or script. Of course, if developer wants to explicitly pause or abandon issue-related work, he/she still can drop a tracking comment.

[japaric]

@Disasm Thanks for the input

This "you are not expected" part is not obvious part at all.

If visibility is an issue we could keep the list private (e.g. https://github.com/orgs/rust-embedded/teams/all) instead of using the "assignee" feature. I personally find the "assignee" feature useful since I can get a list of rust-embedded issues assigned to me using the advanced search feature.

There should be a obvious way to reach the corresponding team

We have team e-mails.

I wonder if GH can notify all team members when someone comments an issue?

@rust-embedded/team-name will cc all team members and subscribe them to the issue. I believe only org members can use it though, but we can cc @rust-embedded/team in the description of the tracking issue and then all team members will be subscribed to it from the beginning.

I think there should be an easy way to signal "paused" state for an issue.

Having an S-paused label, in addition to other 3 status labels mentioned in the RFC, makes sense to me.

[Disasm]

@japaric,

If visibility is an issue we could keep the list private (e.g. https://github.com/orgs/rust-embedded/teams/all) instead of using the "assignee" feature. I personally find the "assignee" feature useful since I can get a list of rust-embedded issues assigned to me using the advanced search feature.

I think that visibility is not an issue, the real problem here is making this tracking thing comfortable for the assignee.

We have team e-mails.

I hope this communication channel works. Will try soon.

@rust-embedded/team-name will cc all team members and subscribe them to the issue. I believe only org members can use it though, but we can cc @rust-embedded/team in the description of the tracking issue and then all team members will be subscribed to it from the beginning.

1. It's not obvious how to ping "team-name". I tried to guess, but failed.
2. Then I tried to reach riscv-team members here (at least those, who showed some activity at the moment) and also failed. I really don't know if this @thing works for me.
   So... if this "tool" works sometimes and sometimes doesn't, it cannot be relied upon.

Having an S-paused label, in addition to other 3 status labels mentioned in the RFC, makes sense to me.

Hmm. I don't see any status labels in the RFC, but it sounds good for me.

[adamgreig]

Looks good. +1 on having S-paused as well.

[mathk]

across all rust-embedded project? That is going to be hard to track.

[mathk]

Will that be part of the triage team duty?