-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify owning team requirement #40
Conversation
This comment has been minimized.
This comment has been minimized.
Fixes: canonical#39 Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
6670e82
to
de95e75
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @cpaelzer !
this reads well and covers everything that is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only have a comment of points before formally approving this PR.
TODO-B: - Team is not yet, but will subscribe to the package before promotion | ||
TODO-A: - The owning team will be TBD and I have their acknowledgement for | ||
TODO-A: that commitment | ||
TODO-B: - I Suggest the owning team to be TBD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think we should have that item here.
In my view, the MIR should not be marked to be reviewing before having an agreement on the owning team. It’s part of the MIR requirements and this requirement should be fullfiled or it will occur maybe undeed review (no team agreeing to take ownership) once it’s reviewed. However, it means, in particular for community, that we need a point of contact for each potential owning team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed
would it be fair to assign a team to review an ownership request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are hereby adding a lot of clarification already in regard to the topic.
Also adding a formal place and process like a point of contact per team is quite an overload - and we all have seen it they keep changing faster than you update a doc/list.
I think when such a MIR request (they are rare) comes in it should be our task (much easier with our context knowledge) to re-reroute this to a requested owning team to say yes/no.
Our check for TODO: A team is committed to own long term maintenance of this package.
together with the duplication and the rationale. And the section ends with
If any of the above checks in this section the MIR team can decide to
skip the rest of the check until these basic questions are resolved.
Due to that there should never be much wasted review time, but OTOH we can help the requester to reach the right team/people. That can then be however we like IRC pings, assignment, ... - depends on the case and team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the rationale on
If any of the above checks in this section the MIR team can decide to skip the rest of the check until these basic questions are resolved.
I’m fine with it thus. I agree that the MIR team may be one the best to reroute the requests too. Note though that each team has an owner, and I think the owner is the PoC and it should (hopefully) be up to date.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
As discussed in the team meeting this tries to address #39 and clarifies the owning team and our earliest "does this make sense to go on" checks in general.
This is a quick write-up of what I had in mind about it, let me know what you think.