Issue Tsardom role specification #14380
Conversation
anatoliykmetyuk
force-pushed
the
issue-tsar-spec
branch
from
de2a6c6 to
08b976f
Compare
| - JVM backend: @sjrd (review only), @Kordyjan | ||
| - Derivation & Mirrors: @bishabosha, (@dwijnand) | ||
| - Linting (especially unused warnings) / Reporting UX : VirtusLab TBD? | ||
| - Java-compat: @Kordyjan |
There was a problem hiding this comment.
/cc @bishabosha @liufengyun @aherlihy @OlivierBlanvillain @abgruszecki @KacperFKorban @BarkingBad @pikinier20 @olhotak @noti0na1 @Kordyjan
CC'ing everyone who wasn't on the meeting where the list was composed – please feel free to submit your corrections if we got something wrong.
Co-authored-by: Paweł Marks <[email protected]>
Co-authored-by: Paweł Marks <[email protected]>
Co-authored-by: Paweł Marks <[email protected]>
| @@ -0,0 +1,75 @@ | |||
| # Issue Tsar Role | |||
There was a problem hiding this comment.
I feel it is time to rename the role to something meaningful such as Issue supervisor. This would help enforce the difference in how this role is taken now that it is a more serious position.
There was a problem hiding this comment.
Yes, I think we need to bring it up at the next Dotty meeting to receive everyone's input about the proper name.
| Other core teammates are responsible for providing information to the Issue Tsar in a timely manner when it is requested if they have that information. | ||
|
|
||
| ## Assignment | ||
| Issue Tsar is appointed for 7 days and is responsible for what is specified in the “Responsibilities” section during those 7 days. Their assumption of the role starts from the Dotty Meeting on Monday and ends on the next Dotty Meeting on Monday. |
There was a problem hiding this comment.
I'm still wondering if it is not better to en on Friday. This way the new person has the time to fully process issues that came on the weekend. But this could be changed later.
There was a problem hiding this comment.
I'm also in favor of this, but during the meeting, the majority seemed to be in favor of the old approach. We can see how it goes and change it in the future if need be.
Co-authored-by: Nicolas Stucki <[email protected]>
Co-authored-by: Nicolas Stucki <[email protected]>
Co-authored-by: Nicolas Stucki <[email protected]>
Co-authored-by: Nicolas Stucki <[email protected]>
Co-authored-by: Jamie Thompson <[email protected]>
This document explicitly specifies a maintenance role that we were already having informally.
[skip ci]