In the last QA meeting it was discussed that we needed some set of policies or guidelines for handling memberships to the QA FAS group for adding karma to the packages within the critical path of F13 (or Fedora CURRENT_RELEASE+1). I volunteered to draft up such a document in the wiki and I snagged a little bit of the wiki mark up from the Ambassadors join page as a template, so thanks to who ever authored that one.
Some notes on my Draft, I thought of putting together policies but I don't entirely find this a policy style situation but I consider it a "case by case" basis just as the Proven Packager process is. Its essentially a "does this person do consistently good QA work?" situation that (in my opinion) should be under review by peers to decide their state of readiness to be responsible for karma that goes into the Critical Path packages.
Ok, intro and disclaimer aside. Here's my proposal: https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft
There are some details on the mentors concept that I think would need working out (denoted by the FIXME bit) that I assume can be worked on at the next QA meeting.
Questions, comments, and snide remarks welcome!
-AdamM
On Fri, 2010-02-26 at 23:55 -0600, Adam Miller wrote:
In the last QA meeting it was discussed that we needed some set of policies or guidelines for handling memberships to the QA FAS group for adding karma to the packages within the critical path of F13 (or Fedora CURRENT_RELEASE+1). I volunteered to draft up such a document in the wiki and I snagged a little bit of the wiki mark up from the Ambassadors join page as a template, so thanks to who ever authored that one.
Some notes on my Draft, I thought of putting together policies but I don't entirely find this a policy style situation but I consider it a "case by case" basis just as the Proven Packager process is. Its essentially a "does this person do consistently good QA work?" situation that (in my opinion) should be under review by peers to decide their state of readiness to be responsible for karma that goes into the Critical Path packages.
That to me makes it feel like it would fit into the SOP (Standard Operating Procedure) mould quite well - just as we currently use for membership of the Bugzappers group.
Ok, intro and disclaimer aside. Here's my proposal: https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft
There are some details on the mentors concept that I think would need working out (denoted by the FIXME bit) that I assume can be worked on at the next QA meeting.
Questions, comments, and snide remarks welcome!
It looks nice - clean and relatively simple. It does have some slightly hand-wavy bits, like 'Once these steps are complete and your mentor feels you versed enough in the processes and methods of the QA Community'. We might want to make that a bit more concrete, as I'm sure you considered too. But I like it so far. Thanks a lot!
On Fri, 2010-02-26 at 23:55 -0600, Adam Miller wrote:
In the last QA meeting it was discussed that we needed some set of policies or guidelines for handling memberships to the QA FAS group for adding karma to the packages within the critical path of F13 (or Fedora CURRENT_RELEASE+1). I volunteered to draft up such a document in the wiki and I snagged a little bit of the wiki mark up from the Ambassadors join page as a template, so thanks to who ever authored that one.
Some notes on my Draft, I thought of putting together policies but I don't entirely find this a policy style situation but I consider it a "case by case" basis just as the Proven Packager process is. Its essentially a "does this person do consistently good QA work?" situation that (in my opinion) should be under review by peers to decide their state of readiness to be responsible for karma that goes into the Critical Path packages.
Ok, intro and disclaimer aside. Here's my proposal: https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft
There are some details on the mentors concept that I think would need working out (denoted by the FIXME bit) that I assume can be worked on at the next QA meeting.
Questions, comments, and snide remarks welcome!
I think this is good, and it dawns on me that releng doesn't need to duplicate this. I'm not sure where the thought first came from to have crit-path voting come from both releng or QA groups, when in reality it could just be a single group that has members who span different areas. It would likely make code easier on the update side too, and make finding somebody to karma up your update easier too. So I'm going to suggest we kill the releng side of this and just go forward with net positive karma from the QA group, and those of us in releng that want to have our vote count can go through the process of getting into the QA group.
Sound reasonable?
On Mon, 2010-03-08 at 17:38 -0800, Jesse Keating wrote:
On Fri, 2010-02-26 at 23:55 -0600, Adam Miller wrote:
In the last QA meeting it was discussed that we needed some set of policies or guidelines for handling memberships to the QA FAS group for adding karma to the packages within the critical path of F13 (or Fedora CURRENT_RELEASE+1). I volunteered to draft up such a document in the wiki and I snagged a little bit of the wiki mark up from the Ambassadors join page as a template, so thanks to who ever authored that one.
Some notes on my Draft, I thought of putting together policies but I don't entirely find this a policy style situation but I consider it a "case by case" basis just as the Proven Packager process is. Its essentially a "does this person do consistently good QA work?" situation that (in my opinion) should be under review by peers to decide their state of readiness to be responsible for karma that goes into the Critical Path packages.
Ok, intro and disclaimer aside. Here's my proposal: https://fedoraproject.org/wiki/QA/JoinCriticalPathWranglers:Draft
There are some details on the mentors concept that I think would need working out (denoted by the FIXME bit) that I assume can be worked on at the next QA meeting.
Questions, comments, and snide remarks welcome!
I think this is good, and it dawns on me that releng doesn't need to duplicate this. I'm not sure where the thought first came from to have crit-path voting come from both releng or QA groups, when in reality it could just be a single group that has members who span different areas. It would likely make code easier on the update side too, and make finding somebody to karma up your update easier too. So I'm going to suggest we kill the releng side of this and just go forward with net positive karma from the QA group, and those of us in releng that want to have our vote count can go through the process of getting into the QA group.
Sound reasonable?
The only thing that worries me about is that it sorta compromises the definition of the 'QA' group in FAS. It's a hostage to future fortune: right now all the 'QA' group would mean is 'people who can approve updates', so it'd be fine...but what if we decide in future we want to use it for something else? We're stuck.
So far QA was planning to use this as an opportunity to actually define a sane policy for the FAS group so that it really reflects the people who are in QA, which would be nice to have for the future.
I think if we just want to make it one group, we should make it a *new* group, called update_approvers or whatever. Members of QA could automatically become members of that group, I guess.
On Mon, 2010-03-08 at 19:06 -0800, Adam Williamson wrote:
The only thing that worries me about is that it sorta compromises the definition of the 'QA' group in FAS. It's a hostage to future fortune: right now all the 'QA' group would mean is 'people who can approve updates', so it'd be fine...but what if we decide in future we want to use it for something else? We're stuck.
So far QA was planning to use this as an opportunity to actually define a sane policy for the FAS group so that it really reflects the people who are in QA, which would be nice to have for the future.
I think if we just want to make it one group, we should make it a *new* group, called update_approvers or whatever. Members of QA could automatically become members of that group, I guess.
Yeah, I'd be fine with a proventesters like group to match up with provenpackagers. It certainly doesn't have to be the QA group, nor do we have to make QA membership automatically put you in proventesters. My point was that it seems wholly unnecessary to have one set of policies to get "QA" people into a group with rights, and then either wholesale copy/paste or slightly modify to get "releng" people into a group with rights. Makes a lot more sense to have one group, one policy, one set of rights.