Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with. (URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html) Jim, if you also proof, given your experience in this area I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch. thx Carl.
Carl, I'm not an expert in this area, but the voting guidelines and explanations are clear enough. One edit though - there is one instance of "whey" instead of "weigh". Jon On 9/9/11 2:08 PM, "Carl Trieloff" <cctrieloff@redhat.com> wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
thx Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
Jon Benedict Technical Marketing Engineer Virtualization & Cloud NetApp 919.476.5093 Direct 919.757.7789 Mobile Jon.Benedict@netapp.com www.netapp.com
fixed. On 09/09/2011 02:25 PM, Benedict, Jon wrote:
Carl,
I'm not an expert in this area, but the voting guidelines and explanations are clear enough. One edit though - there is one instance of "whey" instead of "weigh".
Jon
On 9/9/11 2:08 PM, "Carl Trieloff" <cctrieloff@redhat.com> wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
thx Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
Jon Benedict Technical Marketing Engineer Virtualization & Cloud
NetApp 919.476.5093 Direct 919.757.7789 Mobile Jon.Benedict@netapp.com www.netapp.com
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of community code? One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof. I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM. So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub project. If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions. Regards, Anthony Liguori
thx Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of community code?
One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub project.
If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which rules out the benevolent dictatorship model for sub-projects. The goal here is to build a growing and sustainable community not reliant on single individuals. Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that. Carl.
One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub
project-planning-bounces@ovirt.org wrote on 09/09/2011 03:08:17 PM: project.
If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which rules out the benevolent dictatorship model for sub-projects. The goal here is to build a growing and sustainable community not reliant on single individuals.
Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer per project and I like the rule. I don't think we want to force a change in existing projects that are successful like KVM & QEMU. In both of these cases we have projects with a long history of broad contributions. Or we should recognize that kVM and QEMU have de-facto sub-mainterships due to the practice of regular almost automatic pulling of source trees published by key contributors. Thanks, Mike Mike Day IBM Distinguished Engineer Chief Virtualization Architect, Open Systems Development Cell: +1 919 371-8786 | mdday@us.ibm.com http://code.ncultra.org
On 09/09/2011 03:15 PM, Michael D Day wrote:
One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub
project-planning-bounces@ovirt.org wrote on 09/09/2011 03:08:17 PM: project.
If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which rules out the benevolent dictatorship model for sub-projects. The goal here is to build a growing and sustainable community not reliant on single individuals.
Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer per project and I like the rule. I don't think we want to force a change in existing projects that are successful like KVM & QEMU. In both of these cases we have projects with a long history of broad contributions. Or we should recognize that kVM and QEMU have de-facto sub-mainterships due to the practice of regular almost automatic pulling of source trees published by key contributors.
That seems reasonable. However I think it would be a boost for the respective communities if they voted those key contributors to maintainers if they are defacto trusted and making that recognition public. That in itself is great for all involved, and as from what I understand these key contributors are 'maintainers' in just about every regard except in name and recognition. Formalizing and providing that recognition is never a bad thing. However, I agree, with these listed projects we can make it happen. Carl.
On 09/09/2011 02:29 PM, Carl Trieloff wrote:
On 09/09/2011 03:15 PM, Michael D Day wrote:
project-planning-bounces@ovirt.org wrote on 09/09/2011 03:08:17 PM:
Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer per project and I like the rule. I don't think we want to force a change in existing projects that are successful like KVM& QEMU. In both of these cases we have projects with a long history of broad contributions. Or we should recognize that kVM and QEMU have de-facto sub-mainterships due to the practice of regular almost automatic pulling of source trees published by key contributors.
That seems reasonable. However I think it would be a boost for the respective communities if they voted those key contributors to maintainers if they are defacto trusted and making that recognition public. That in itself is great for all involved, and as from what I understand these key contributors are 'maintainers' in just about every regard except in name and recognition. Formalizing and providing that recognition is never a bad thing.
No, it's formalized already (via a MAINTAINERS file, just like Linux). Again, this is very similar to other communities like libvirt. If one of the Daniels are on the list, they can comment more, but my understand is that there are many people with commit access, but a very small number of people that are effectively the benevolent dictators and make final decisions on releases. The main point here is not to debate the effectiveness of any given model but to point out that the stricter you are about requiring projects to govern themselves in certain ways, the less inclusive the overall community will be. Regards, Anthony Liguori
However, I agree, with these listed projects we can make it happen.
Carl.
On 09/09/2011 03:40 PM, Anthony Liguori wrote:
On 09/09/2011 02:29 PM, Carl Trieloff wrote:
On 09/09/2011 03:15 PM, Michael D Day wrote:
project-planning-bounces@ovirt.org wrote on 09/09/2011 03:08:17 PM:
Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that.
I agree that we need to encourage and require more than one maintainer per project and I like the rule. I don't think we want to force a change in existing projects that are successful like KVM& QEMU. In both of these cases we have projects with a long history of broad contributions. Or we should recognize that kVM and QEMU have de-facto sub-mainterships due to the practice of regular almost automatic pulling of source trees published by key contributors.
That seems reasonable. However I think it would be a boost for the respective communities if they voted those key contributors to maintainers if they are defacto trusted and making that recognition public. That in itself is great for all involved, and as from what I understand these key contributors are 'maintainers' in just about every regard except in name and recognition. Formalizing and providing that recognition is never a bad thing.
No, it's formalized already (via a MAINTAINERS file, just like Linux).
Again, this is very similar to other communities like libvirt. If one of the Daniels are on the list, they can comment more, but my understand is that there are many people with commit access, but a very small number of people that are effectively the benevolent dictators and make final decisions on releases.
The main point here is not to debate the effectiveness of any given model but to point out that the stricter you are about requiring projects to govern themselves in certain ways, the less inclusive the overall community will be.
apache also has the two levels, they call that the PMC. I stripped the two levels out to keep it simple and we can update as required. If we want that we should doc it back in. goal here is to be transparent and easy for people to join in. carl
On 09/09/2011 02:08 PM, Carl Trieloff wrote:
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of community code?
One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub project.
If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which rules out the benevolent dictatorship model for sub-projects. The goal here is to build a growing and sustainable community not reliant on single individuals.
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote. It's the same model as the kernel and many other communities. Regards, Anthony Liguori
On 09/09/2011 03:37 PM, Anthony Liguori wrote:
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
how about we state that a sub-project may ellect someone to cast tie breaking votes if they want to. And then how that loosely works I think that should resolve your concern. Does that work? Carl.
On 09/09/2011 02:54 PM, Carl Trieloff wrote:
On 09/09/2011 03:37 PM, Anthony Liguori wrote:
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
how about we state that a sub-project may ellect someone to cast tie breaking votes if they want to. And then how that loosely works
I think that should resolve your concern. Does that work?
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures. Regards, Anthony Liguori
Carl.
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves. Do you want to go ahead and edit that into the google doc? Carl.
On 09/09/2011 04:03 PM, Carl Trieloff wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
On 09/09/2011 04:00 PM, Anthony Liguori wrote: that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Do you want to go ahead and edit that into the google doc?
Anthony, I added a section at the bottom, take a look and see if it cuts mustard for you. edit away as needed. thx Carl.
On 09/09/2011 03:25 PM, Carl Trieloff wrote:
On 09/09/2011 04:03 PM, Carl Trieloff wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
On 09/09/2011 04:00 PM, Anthony Liguori wrote: that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Do you want to go ahead and edit that into the google doc?
Anthony,
I added a section at the bottom, take a look and see if it cuts mustard for you. edit away as needed.
I think that's sufficiently open ended enough that it can be clarified down the road through board voting. Thanks! Regards, Anthony Liguori
thx Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects: Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project. Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model. Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board? I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass. Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
Do you want to go ahead and edit that into the google doc?
Sure. Regards, Anthony Liguori
Carl.
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
That looks nice, I cut and paste this into the doc I working now -- called - becoming an oVirt sub-project Carl.
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
Do we define a maintainer as anyone with commit access to the main upstream repo? If so, oVirt Node project has 3 maintainers presently (not counting myself, and I don't since I don't code anymore...) Perry
On 09/09/2011 04:09 PM, Perry Myers wrote:
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x< 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3<= x< 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x>= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
Do we define a maintainer as anyone with commit access to the main upstream repo?
If so, oVirt Node project has 3 maintainers presently (not counting myself, and I don't since I don't code anymore...)
I think anyone with commit access who can commit other people's patches? I think that fits the categories quite well too. ovirt-node is large enough that it should be autonomous. I think the overall goal is to make sure that projects move from Tier 0 -> Tier 1 over time but once at Tier 1, I'm sure certain projects can last forever at that size. Regards, Anthony Liguori
Perry
On 09/09/2011 05:30 PM, Anthony Liguori wrote:
On 09/09/2011 04:09 PM, Perry Myers wrote:
On 09/09/2011 04:38 PM, Anthony Liguori wrote:
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x< 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3<= x< 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x>= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
They are now listed in the google doc. Itamar is still filling in the matrix.
Do we define a maintainer as anyone with commit access to the main upstream repo?
yes.
If so, oVirt Node project has 3 maintainers presently (not counting myself, and I don't since I don't code anymore...)
I think anyone with commit access who can commit other people's patches?
I think that fits the categories quite well too. ovirt-node is large enough that it should be autonomous. I think the overall goal is to make sure that projects move from Tier 0 -> Tier 1 over time but once at Tier 1, I'm sure certain projects can last forever at that size.
Regards,
Anthony Liguori
Perry
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony Liguori Sent: Friday, September 09, 2011 23:39 PM To: cctrieloff@redhat.com Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is valid for projects with less than 10 maintainers as well. This is also relevant for overruling a nack to avoid stagnation. A majority of acks, or leader as tie breaker should be able to vote on overruling a nack.
Looks good. Could use some editing (lots of small things like s/rewording/rewarding/, s/wsdm/vdsm/) ----- Original Message -----
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony Liguori Sent: Friday, September 09, 2011 23:39 PM To: cctrieloff@redhat.com Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
On 09/09/2011 03:03 PM, Carl Trieloff wrote:
On 09/09/2011 04:00 PM, Anthony Liguori wrote:
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves.
Okay, that sounds good. Perhaps we should try to work language like this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects).
I think the comment on a 'leader' and the need for a tie breaker is valid for projects with less than 10 maintainers as well. This is also relevant for overruling a nack to avoid stagnation. A majority of acks, or leader as tie breaker should be able to vote on overruling a nack. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
-- --------------------------------------------------------------- "We are all on earth to help others. What on earth the others are here for, I can't imagine." Reverend Vivian Foster, Vicar of Mirth.
On 09/11/2011 03:57 AM, Itamar Heim wrote:
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony Liguori Sent: Friday, September 09, 2011 23:39 PM To: cctrieloff@redhat.com Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
I'd prefer something like, communities with greater than 3 (or maybe 10?) maintainers can creator their own voting procedures.
On 09/09/2011 04:00 PM, Anthony Liguori wrote: that is what apache does btw and is fine by me. the goal here is to get a broad maintainer set and help mew projects grow. once a project has a good culture, they can evolve it themselves. Okay, that sounds good. Perhaps we should try to work language like
On 09/09/2011 03:03 PM, Carl Trieloff wrote: this into more of these docs? Basically, three tiers of projects:
Tier 0; x < 3 maintainers, oVirt board has ability to make decisions on behalf of the project.
Tier 1; 3 <= x < 10 maintainers, project is autonomous, but must use oVirt recommended voting procedures and maintainership model.
Tier 2; x >= 10 maintainers, project is autonomous and writes its own governance document. Perhaps the document should be voted on by the oVirt board?
I think that creates a nice incubator model where oVirt helps a project grow and gets out of the way once it reaches critical mass.
Can anyone give me an idea of where the initial set of seed projects will fit? How many maintainers is oVirt Server likely to have? (I assume that's the biggest of the seed projects). I think the comment on a 'leader' and the need for a tie breaker is valid for projects with less than 10 maintainers as well. This is also relevant for overruling a nack to avoid stagnation. A majority of acks, or leader as tie breaker should be able to vote on overruling a nack.
I'll draft a first version of the becoming a sub-project doc, and I'll try work this feedback into that. Carl.
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works. The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required… If half the community thinks A and the other B, then there is for sure no consensus.
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Jim Jagielski Sent: Tuesday, September 13, 2011 16:54 PM To: Anthony Liguori Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required. If half the community thinks A and the other B, then there is for sure no consensus.
How often are these and how do they get resolved? How is a nack by someone resolved if majority are in agreement (ack it)?
Having 3 maintainers does not mean there isn't an overall project
leader. We have around 30 maintainers
in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
_______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
On 09/13/2011 10:01 AM, Itamar Heim wrote:
How often are these and how do they get resolved? How is a nack by someone resolved if majority are in agreement (ack it)?
A nack is invalid (an has to be withdrawn) unless solid technical reason are given and the debate around those reasons hold. Jim -- want to add? Carl.
On Sep 13, 2011, at 10:25 AM, Carl Trieloff wrote:
On 09/13/2011 10:01 AM, Itamar Heim wrote:
How often are these and how do they get resolved? How is a nack by someone resolved if majority are in agreement (ack it)?
A nack is invalid (an has to be withdrawn) unless solid technical reason are given and the debate around those reasons hold.
Jim -- want to add?
Yep, that's right. In Apache-speak, it's called a 'veto' -- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Jim Jagielski Sent: Tuesday, September 13, 2011 17:27 PM To: cctrieloff@redhat.com Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
On Sep 13, 2011, at 10:25 AM, Carl Trieloff wrote:
On 09/13/2011 10:01 AM, Itamar Heim wrote:
How often are these and how do they get resolved? How is a nack by someone resolved if majority are in agreement (ack it)?
A nack is invalid (an has to be withdrawn) unless solid technical reason are given and the debate around those reasons hold.
Jim -- want to add?
Yep, that's right. In Apache-speak, it's called a 'veto'
How often do these happen?
On 09/14/2011 06:24 AM, Itamar Heim wrote:
Yep, that's right. In Apache-speak, it's called a 'veto' How often do these happe
I see one that results in debate about every 2+ years on the one project I run. You may see them on a release vote during testing if issues are found or licenses missing etc, typically the a patch is submitted to resolve it and the vote goes on. Most time feedback is taken and code is improved through normal working. Carl.
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required… If half the community thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie break role. This is different to ASF. Jim brings up a good point and the question is do we want it, or not? Might be best to remove it, and then if a project wants it they have to get to the mature phase of the project where they update their voting rules if they want to add that role. thoughts? Carl.
That's most probably a good path. If you start off with the expectation that there will be the need for tie-breaking votes, well… they are bound to happen. But if the expectation is that there will be no need for them, and therefore no position that is "empowered" to break them, then the communities will be "forced" to collaborate and compromise. On Sep 13, 2011, at 10:02 AM, Carl Trieloff wrote:
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required… If half the community thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie break role. This is different to ASF. Jim brings up a good point and the question is do we want it, or not?
Might be best to remove it, and then if a project wants it they have to get to the mature phase of the project where they update their voting rules if they want to add that role.
thoughts?
Carl.
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
On 09/13/2011 09:02 AM, Carl Trieloff wrote:
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required… If half the community thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie break role. This is different to ASF. Jim brings up a good point and the question is do we want it, or not?
As long as we're preserving autonomy for established projects, I think any model as long as it's consistent for smaller projects would work. Regards, Anthony Liguori
Might be best to remove it, and then if a project wants it they have to get to the mature phase of the project where they update their voting rules if they want to add that role.
thoughts?
Carl.
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Anthony Liguori Sent: Tuesday, September 13, 2011 18:11 PM To: cctrieloff@redhat.com Cc: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
On 09/13/2011 09:02 AM, Carl Trieloff wrote:
On 09/13/2011 09:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required. If half the community thinks A and the other B, then there is for sure no consensus.
I know many of the Linux projects use the concept of a group elected tie break role. This is different to ASF. Jim brings up a good point and
the
question is do we want it, or not?
As long as we're preserving autonomy for established projects, I think any model as long as it's consistent for smaller projects would work.
Do we count ovirt engine as an established project :) ? I think our current model is of a tie breaking vote in case of disagreement...
On 09/14/2011 06:24 AM, Itamar Heim wrote:
As long as we're preserving autonomy for established projects, I think
any model as long as it's consistent for smaller projects would work. Do we count ovirt engine as an established project :) ? I think our current model is of a tie breaking vote in case of disagreement...
I think we want board ack one the first few releases of engine so we can get our community release processes documented. Carl.
On 09/13/2011 08:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required…
That's one model, but it's not the only model. As it happens, there's a good LWN article right now on this topic. http://lwn.net/Articles/458094/ The simple fact is, a large part of the ecosystem we're trying to build is already existing and has a diverse development model. If we don't accommodate development model diversity, then we're going to exclude large parts of the ecosystem which is going to result in fragmentation. Regards, Anthony Liguori
If half the community thinks A and the other B, then there is for sure no consensus.
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
http://webmink.com/2011/03/11/is-apache-open-by-rule/ On Sep 13, 2011, at 11:06 AM, Anthony Liguori wrote:
On 09/13/2011 08:54 AM, Jim Jagielski wrote:
A project lead implies that somehow his/her vote is more important than anyone else's, which is not how the ASF works.
The idea is to build a community that strives for consensus so that the need for tie-breaking votes isn't required…
That's one model, but it's not the only model. As it happens, there's a good LWN article right now on this topic.
http://lwn.net/Articles/458094/
The simple fact is, a large part of the ecosystem we're trying to build is already existing and has a diverse development model. If we don't accommodate development model diversity, then we're going to exclude large parts of the ecosystem which is going to result in fragmentation.
Regards,
Anthony Liguori
If half the community thinks A and the other B, then there is for sure no consensus.
Having 3 maintainers does not mean there isn't an overall project leader. We have around 30 maintainers in QEMU but only one project leader. The project leader casts the tie breaking vote.
It's the same model as the kernel and many other communities.
Regards,
Anthony Liguori
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
++1 On Sep 9, 2011, at 3:08 PM, Carl Trieloff wrote:
On 09/09/2011 02:48 PM, Anthony Liguori wrote:
On 09/09/2011 01:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
= (URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
I assume code doesn't mean code as in software, but some sort of community code?
One concern I have is that this seems to enforce that all projects are managed via consensus. But many existing (and successful) Open Source projects don't use an Apache-style consensus model but rather rely on a benevolent dictatorship or some variation thereof.
I think it's fine to use a consensus model for oVirt business, but I think it's important to allow sub projects to use other types of leadership models. Otherwise you're excluding large parts of the existing community, most notably, libvirt, QEMU, and KVM.
So I think for project specific things (like whether a project is ready for a release) needs to be completely deferred to the sub project.
If the sub project needs to somehow codify how it makes decisions, that's fine, but the sub project should ultimately have the say over how it makes decisions.
The goal is for each sub-project to get to 3 or more maintainers, which rules out the benevolent dictatorship model for sub-projects. The goal here is to build a growing and sustainable community not reliant on single individuals.
Think of it as at least three benevolent dictators per sub-project, or if the project has less than three, the board helps provide accountability. For projects like KVM, QEMU, libvirt, if they joined in we would encourage them vote on additional maintainers. It is hard to argue any downside to doing that.
Carl.
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
Will do… On Sep 9, 2011, at 2:08 PM, Carl Trieloff wrote:
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
thx Carl.
-- Jim Jagielski | jimjag@redhat.com | 443-324-8390 (cell)
cc'ing some existing leads to comment on this one as well.
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Friday, September 09, 2011 21:08 PM To: project-planning@ovirt.org; Jim Jagielski Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
thx Carl. _______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl Trieloff Sent: Friday, September 09, 2011 21:08 PM To: project-planning@ovirt.org; Jim Jagielski Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
Another thought/issue: Currently maintainer == committer. Ovirt engine has multiple modules in it. While a lot of people have commit rights, they are not considered maintainers of the entire project. However, it makes sense for them to commit the holistic patch across multiple modules once all acks are given. So to me, a maintainer is someone who can ack a patch for a certain module A committer can commit code, but is responsible to not commit without an ack from the relevant maintainer if the patch encompasses subsystems outside of his domain expertise (i.e., committer is not maintainer in all portions the patch set will touch) Thoughts?
On 09/14/2011 01:27 PM, Itamar Heim wrote:
-----Original Message----- From: project-planning-bounces@ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
Trieloff Sent: Friday, September 09, 2011 21:08 PM To: project-planning@ovirt.org; Jim Jagielski Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure it is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
Another thought/issue: Currently maintainer == committer. Ovirt engine has multiple modules in it. While a lot of people have commit rights, they are not considered maintainers of the entire project. However, it makes sense for them to commit the holistic patch across multiple modules once all acks are given.
So to me, a maintainer is someone who can ack a patch for a certain module A committer can commit code, but is responsible to not commit without an
Another question here - when you speak of modules - are you referring also for sub modules, for example - the bll and dal modules in engine core?
ack from the relevant maintainer if the patch encompasses subsystems outside of his domain expertise (i.e., committer is not maintainer in all portions the patch set will touch)
Thoughts?
_______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
-----Original Message----- From: project-planning-bounces@ovirt.org [mailto:project-planning-bounces@ovirt.org] On Behalf Of Yair Zaslavsky Sent: Wednesday, September 14, 2011 16:34 PM To: project-planning@ovirt.org Subject: Re: oVirt comminuty voting
On 09/14/2011 01:27 PM, Itamar Heim wrote:
-----Original Message----- From: project-planning-bounces@ovirt.org
[mailto:project-planning-bounces@ovirt.org] On Behalf Of Carl
Trieloff Sent: Friday, September 09, 2011 21:08 PM To: project-planning@ovirt.org; Jim Jagielski Subject: oVirt comminuty voting
Please read, we can always vote in updates, so proof it and make sure
it
is good enough to get going with.
(URL REDACTED - INFO: http://lists.ovirt.org/mailman/project-planning/2011-September/000283.html)
Jim, if you also proof, given your experience in this area
I have linked it into the web site layout in the google doc, I'll be working all the key sections one by one to get us going for launch.
Another thought/issue: Currently maintainer == committer. Ovirt engine has multiple modules in it. While a lot of people have commit rights, they are not considered maintainers of the entire project. However, it makes sense for them to commit the holistic patch across multiple modules once all acks are given.
So to me, a maintainer is someone who can ack a patch for a certain module A committer can commit code, but is responsible to not commit without an
Another question here - when you speak of modules - are you referring also for sub modules, for example - the bll and dal modules in engine core?
I was thinking more across what we call projects, but we could define same level of granularity to regions in the engine core itself as well.
ack from the relevant maintainer if the patch encompasses subsystems outside of his domain expertise (i.e., committer is not maintainer in
all
portions the patch set will touch)
Thoughts?
_______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
_______________________________________________ Project-planning mailing list Project-planning@ovirt.org http://lists.ovirt.org/mailman/listinfo/project-planning
participants (9)
-
Anthony Liguori -
Ayal Baron -
Benedict, Jon -
Carl Trieloff -
Itamar Heim -
Jim Jagielski -
Michael D Day -
Perry Myers -
Yair Zaslavsky