Hi folks,
One discussion we didn't get to finish in today's meeting was the membership section of Jóhann's governance charter draft. As stated during the meeting, he felt having this cross-section of Fedora would "ensure coverage and proper release process for server product."
The draft link is here, for convenience: https://fedoraproject.org/wiki/User:Johannbg/ServerWG
After the meeting I went back to the Fedora.next proposal to see what it says about membership in the working groups and read this:
"There will be at least one FESCo member in each to act as a liaison. There should be a liaison with the QA, rel eng, docs, marketing, and web/infrastructure groups as well although these may not be people from those teams but people tasked with facilitating dialogue between those groups and the working group instead."
Jóhann's proposal seems to follow the spirit of this (adding the design team as a group needing representation; thank you for that. :) ) With that in mind I've changed my position on this matter a bit, and I would like to hear your thoughts on this proposal:
- The proposal says we would continue to have nine voting members, but then talks about there being a member each to represent 7 Fedora groups and 3 additional members to represent the server community itself. I think the representation of the server community itself is too slim here, and I think the slots could overlap.
- I would like to propose instead that we maintain a nine voting member roster, but require that at least five of the members be able to directly represent the server community. By this, I specifically would like to require any or all of the following requirements be met by a 'server community' representative (under which all of our current 'server community' reps and other members qualify as well):
- member has worked professionally as a system administrator for a deployment of at least 10 production servers - member has been involved significantly as a contributor to an enterprise Linux distribution or enterprise management product for Linux servers.
- Instead of having each of the cross-section teams across Fedora (docs, rel-eng, QA, ambassadors, infra, design, marketing) have a member of their team directly serving in the Server working group, I would like to suggest instead following the Fedora.next proposal suggestion that each of these teams have a liaison on the working group who isn't necessarily a member of the team they represent. So, for example, Stephen could be the liaison for the Fedora marketing team even though he is not a member of that team, and whenever the working group needs to interface with that team it would be Stephen's responsibility to contact them. So each team has a 'go-to' person on our working group, and our working group has a 'go-to' person for each team we'd need to interface with. To have the same person managing the relationship could simplify communications.
- In order to determine who is the liaison for which of the 7 groups, for now we could go with people who are a member of the groups are the liaison and groups that do not have a member on the working group would have a member not already a liaison for another team nominated to be their liasion. When someone who is the liaison for a given Fedora team leaves the group, that group will be given the opportunity to suggest a replacement but the decision as to who to pick would ultimately be up to the remaining members of the working group.
With this proposal in mind -
I am still not sure how the turnover works. Do we serve until we're sick of serving, or is there a term / period we are on and then are up for re-elections? The draft does not cover this really.
Anyway, let's discuss :)
~m
On 10/30/2013 08:54 PM, Máirín Duffy wrote:
Hi folks,
One discussion we didn't get to finish in today's meeting was the membership section of Jóhann's governance charter draft. As stated during the meeting, he felt having this cross-section of Fedora would "ensure coverage and proper release process for server product."
The draft link is here, for convenience: https://fedoraproject.org/wiki/User:Johannbg/ServerWG
After the meeting I went back to the Fedora.next proposal to see what it says about membership in the working groups and read this:
"There will be at least one FESCo member in each to act as a liaison. There should be a liaison with the QA, rel eng, docs, marketing, and web/infrastructure groups as well although these may not be people from those teams but people tasked with facilitating dialogue between those groups and the working group instead."
Jóhann's proposal seems to follow the spirit of this (adding the design team as a group needing representation; thank you for that. :) ) With that in mind I've changed my position on this matter a bit, and I would like to hear your thoughts on this proposal:
Actually FESCo revisited the requirement of one of it's member having to be a member of each WG ( with the exception of the initial one of course ) to just there has to be appointed liason.
- The proposal says we would continue to have nine voting members, but
then talks about there being a member each to represent 7 Fedora groups and 3 additional members to represent the server community itself. I think the representation of the server community itself is too slim here, and I think the slots could overlap.
Actually that was just a counting mistake on my behalf it was always meant to be nine members. ( mathematically it always has to be made up of odd number anyway to prevent votes ending in ties )
- I would like to propose instead that we maintain a nine voting member
roster, but require that at least five of the members be able to directly represent the server community. By this, I specifically would like to require any or all of the following requirements be met by a 'server community' representative (under which all of our current 'server community' reps and other members qualify as well):
- member has worked professionally as a system administrator for a
deployment of at least 10 production servers
- member has been involved significantly as a contributor to an
enterprise Linux distribution or enterprise management product for Linux servers.
There was an attempt in the QA community back in the day where there was this attempt to have all testers to be required to have RHSA or RHCE which just laughable so needles to sayI disagree since adding an requirement like this will never work because obviously you have no way of actually verifying this in addition just because individual meets set requirements he still might not be up to the task so to speak or more likely to be so + adding a requirement like this for participation will drive away potential contributors. ( those contributors might make up them not meeting the said requirements by pure enthusiasm and the more experience would just help guide that energy into the right places )
- Instead of having each of the cross-section teams across Fedora (docs,
rel-eng, QA, ambassadors, infra, design, marketing) have a member of their team directly serving in the Server working group, I would like to suggest instead following the Fedora.next proposal suggestion that each of these teams have a liaison on the working group who isn't necessarily a member of the team they represent. So, for example, Stephen could be the liaison for the Fedora marketing team even though he is not a member of that team, and whenever the working group needs to interface with that team it would be Stephen's responsibility to contact them. So each team has a 'go-to' person on our working group, and our working group has a 'go-to' person for each team we'd need to interface with. To have the same person managing the relationship could simplify communications.
- In order to determine who is the liaison for which of the 7 groups,
for now we could go with people who are a member of the groups are the liaison and groups that do not have a member on the working group would have a member not already a liaison for another team nominated to be their liasion. When someone who is the liaison for a given Fedora team leaves the group, that group will be given the opportunity to suggest a replacement but the decision as to who to pick would ultimately be up to the remaining members of the working group.
Actually after going through an PDR I actually come more to the conclusion that this is more an requirement that we should have and if we do not we should either exercise this clause in my proposal "If there are no candidates available, the existing remaining members of the Server WG will fill the seat by selecting a candidate and approving by majority consensus." and pump the number of server community members to 11 or 13 ( we are going to need all those people anyway. )
Now having said that after going through an PDR, an PDR cannot be applied to the server WG since in fact it is the documentation which will be describing the transition process from an server application that we ship to an "product" so as I see it the initial server WG is setting the framework for that as well as pushing 3 products ( to iron out any issue in that process ) through the transition process and through that framework.
Ones that has been achieve the role of the server WG will be more selecting which application to choose next and push it through that process.
With this proposal in mind -
I am still not sure how the turnover works. Do we serve until we're sick of serving, or is there a term / period we are on and then are up for re-elections? The draft does not cover this really.
There should be just one election and that's for the server group that will replaces the initial *chosen* WG after that there should not be any other elections that's a burden we do not want in a process like this so we either do as my proposal indicates which is to have each composition group being responsabile for chosing their member to appoint to their respective seat by or the individual stepping down selects another individual to take his place or better yet the remaining members of the WG choose an individual to take that seat.
Well that concludes my thoughts and comments ;)
JBG
On 10/30/2013 06:05 PM, "Jóhann B. Guðmundsson" wrote:
Actually FESCo revisited the requirement of one of it's member having to be a member of each WG ( with the exception of the initial one of course ) to just there has to be appointed liason.
Oh okay, I was unaware of this, thanks for pointing it out. Is there any place where I can read more about this so I have more of the background?
Actually that was just a counting mistake on my behalf it was always meant to be nine members. ( mathematically it always has to be made up of odd number anyway to prevent votes ending in ties )
Okay, makes sense. I wasn't sure if the intention was to be 9 or 10.
There was an attempt in the QA community back in the day where there was this attempt to have all testers to be required to have RHSA or RHCE which just laughable so needles to sayI disagree since adding an requirement like this will never work because obviously you have no way of actually verifying this in addition just because individual meets set requirements he still might not be up to the task so to speak or more likely to be so + adding a requirement like this for participation will drive away potential contributors.
Your draft says, "the remaining two members coming from the Server Community itself" so my suggested requirement of system administration or enterprise OS experience is an attempt to qualify whether or not one comes from the 'server community.' If you think that specific illustration of what coming from the server community mean isn't good, can you maybe provide what you were specifically thinking of when you mentioned 'server community,' in your draft? Who were you thinking of / how would you define such a person?
To be fair, I don't think requiring either system administrator experience or experience working on an enterprise OS is so rigorous a requirement as a Red Hat certification. I also don't think we have to verify it; it's unlikely some unknown person from left field who we aren't already friends with / familiar with from around Fedora is going to show up, right? But certainly, I think it would help to have people who have this experience make up the majority (5) of the group because don't you need to understand about how servers are used to understand how to develop a successful server product? My training / background / experience as a UX designer at least has always pointed towards understanding your user's needs as most important to developing a good product.
How do you think the requirement would drive away potential contributors? How many of the self-nominated folks who showed interest in joining the group would qualify? Most if not all of us in the group would qualify. Do you think the risk of driving away folks is greater than the value of having this experience on the team is?
( those contributors might make up them not meeting the said requirements by pure enthusiasm and the more experience would just help guide that energy into the right places )
Couldn't they take one of the four seats that doesn't require the background?
Actually after going through an PDR
Which one?
I actually come more to the conclusion that this is more an requirement that we should have and if we do not we should either exercise this clause in my proposal "If there are no candidates available, the existing remaining members of the Server WG will fill the seat by selecting a candidate and approving by majority consensus." and pump the number of server community members to 11 or 13 ( we are going to need all those people anyway. )
I'm worried that having more people in the group would make it unnecessarily challenging to manage and come to consensus on things - even to come up with a time slot that everyone could make on a regular basis. May I ask how, specifically, do you envision having that many extra people being helpful - what would they do? What would they bring to the group that it would lack otherwise being 9 people?
Now having said that after going through an PDR, an PDR cannot be applied to the server WG since in fact it is the documentation which will be describing the transition process from an server application that we ship to an "product" so as I see it the initial server WG is setting the framework for that as well as pushing 3 products ( to iron out any issue in that process ) through the transition process and through that framework.
Ones that has been achieve the role of the server WG will be more selecting which application to choose next and push it through that process.
I don't follow; can you explain a little bit more what you mean here? I don't think the server working group is pushing 3 products; isn't the server one of three products? (The three being server, cloud, workstation?) Or am I missing a reference here?
There should be just one election and that's for the server group that will replaces the initial *chosen* WG after that there should not be any other elections that's a burden we do not want in a process like this so we either do as my proposal indicates which is to have each composition group being responsabile for chosing their member to appoint to their respective seat by or the individual stepping down selects another individual to take his place or better yet the remaining members of the WG choose an individual to take that seat.
In your opinion, is the current composition of the working group is temporary and just to set up the framework, then there should be a one-time election to elect the real working group? After which point there will be no elections but each member would step down at their leisure and choose their replacement with the rest of the group's approval?
~m
On Wed, Oct 30, 2013 at 08:55:27PM -0400, Máirín Duffy wrote:
Oh okay, I was unaware of this, thanks for pointing it out. Is there any place where I can read more about this so I have more of the background?
Fesco meeting logs. I'll try to do a better job at updating the wiki at https://fedoraproject.org/wiki/Fedora.next with the Current State of All the Things.
On 10/31/2013 12:55 AM, Máirín Duffy wrote:
On 10/30/2013 06:05 PM, "Jóhann B. Guðmundsson" wrote:
Actually FESCo revisited the requirement of one of it's member having to be a member of each WG ( with the exception of the initial one of course ) to just there has to be appointed liason.
Oh okay, I was unaware of this, thanks for pointing it out. Is there any place where I can read more about this so I have more of the background?
It go decided on the fesco meeting that was held straight after our meeting so it's no wonder you might have missed it ;)
Your draft says, "the remaining two members coming from the Server Community itself" so my suggested requirement of system administration or enterprise OS experience is an attempt to qualify whether or not one comes from the 'server community.' If you think that specific illustration of what coming from the server community mean isn't good, can you maybe provide what you were specifically thinking of when you mentioned 'server community,'
The role of server administrators
in your draft? Who were you thinking of / how would you define such a person?
Person that is active in his field but in essence you cannot apply any particular role to a community of volunteers since the role they play is what matters to *them* and what *they* decide at the moment they contribute *their free time* to it.
To be fair, I don't think requiring either system administrator experience or experience working on an enterprise OS is so rigorous a requirement as a Red Hat certification. I also don't think we have to verify it; it's unlikely some unknown person from left field who we aren't already friends with / familiar with from around Fedora is going to show up, right?
Apply what you just said to the entire nominators for all the working groups
But certainly, I think it would help to have people who have this experience make up the majority (5) of the group because don't you need to understand about how servers are used to understand how to develop a successful server product?
Yes to develop a server product, for PRD no you dont.
My training / background / experience as a UX designer at least has always pointed towards understanding your user's needs as most important to developing a good product.
How do you think the requirement would drive away potential contributors?
Simple because by doing that you are adding a barrier of entry and at the same time forming a group of elites.
( those contributors might make up them not meeting the said requirements by pure enthusiasm and the more experience would just help guide that energy into the right places )
Couldn't they take one of the four seats that doesn't require the background?
Actually after going through an PDR
Which one?
Actual there where several I went through to see the common denominator in them so I could start writing a sample draft for us to start working on.
I actually come more to the conclusion that this is more an requirement that we should have and if we do not we should either exercise this clause in my proposal "If there are no candidates available, the existing remaining members of the Server WG will fill the seat by selecting a candidate and approving by majority consensus." and pump the number of server community members to 11 or 13 ( we are going to need all those people anyway. )
I'm worried that having more people in the group would make it unnecessarily challenging to manage and come to consensus on things - even to come up with a time slot that everyone could make on a regular basis.
PRD are very specific in their nature and function and can only be applied to a single product not community of products let alone on a community of volunteers.
Applying it to these 3 groups will fail in the same manner as you tried to apply it to Red Hat as a company or Fedora in whole as in making a single product out of both of these.
And afaik I know the other half and the presiding one required to make it work is the MRD which the community should have done first and that part has been conveniently left out by the individuals driving this.
May I ask how, specifically, do you envision having that many extra people being helpful - what would they do? What would they bring to the group that it would lack otherwise being 9 people?
You need everyone one on board and all hands on deck to have the slightest chance of achieving this.
The function of the voting member is more of steering the ship then dictate the direction as in ensuring that we get from point a) to point b) and stay on course
In the end of the day only thing we actually would need to vote upon ( as I see it ) is which server application we make the first product out of and that's a vote everyone should be a part of anyway.
Now having said that after going through an PDR, an PDR cannot be applied to the server WG since in fact it is the documentation which will be describing the transition process from an server application that we ship to an "product" so as I see it the initial server WG is setting the framework for that as well as pushing 3 products ( to iron out any issue in that process ) through the transition process and through that framework.
Ones that has been achieve the role of the server WG will be more selecting which application to choose next and push it through that process.
I don't follow; can you explain a little bit more what you mean here? I don't think the server working group is pushing 3 products; isn't the server one of three products? (The three being server, cloud, workstation?) Or am I missing a reference here?
You cannot apply PRD to those product again PRD are very specific in their nature and function
There should be just one election and that's for the server group that will replaces the initial *chosen* WG after that there should not be any other elections that's a burden we do not want in a process like this so we either do as my proposal indicates which is to have each composition group being responsabile for chosing their member to appoint to their respective seat by or the individual stepping down selects another individual to take his place or better yet the remaining members of the WG choose an individual to take that seat.
In your opinion, is the current composition of the working group is temporary and just to set up the framework,
Not in my opinion afaik there is supposed to be election in January in every WG to let each group re-elect or replace the initial pointed members but maybe I misunderstood something.
then there should be a one-time election to elect the real working group?
It's left for the relevant sub community to decide they might as well appoint someone as I see you need individuals from within those community to make PRD work.
After which point there will be no elections but each member would step down at their leisure and choose their replacement with the rest of the group's approval?
For the first this Fedora is an community of volunteers so if people feel they don't like doing some thing they stop doing it or as you phrase it "step down at their leisure" so you will never be able to force people to do something they dont want to do and having them choosing their replacement within the group that avoids the issue of finding a new one. ( Unless the replacement is not approved =
Attempting to apply PRD on a community of volunteers is rather bold move and we dont even have proper tools to do PRD and track them and their progress properly and so efficiently in the project.
JBG
On Thu, Oct 31, 2013 at 05:30:49PM +0000, "Jóhann B. Guðmundsson" wrote:
And afaik I know the other half and the presiding one required to make it work is the MRD which the community should have done first and that part has been conveniently left out by the individuals driving this.
I don't know how "convenient" it is. We're not really selling anything so we don't have a market in the classical sense. But, I (as an individual) certainly assumed that sort-of-equivalent work would indeed be done as part of building the PRD, and that's what we're doing in the Cloud group.
On 10/31/2013 07:07 PM, Matthew Miller wrote:
I don't know how "convenient" it is. We're not really selling anything so we don't have a market in the classical sense. But, I (as an individual) certainly assumed that sort-of-equivalent work would indeed be done as part of building the PRD, and that's what we're doing in the Cloud group.
But you do realize that's what the entire PRD is about? And you do realize we need a properly made MRD by *marketing people* that will analyse our competitors to make a successfully PRD right?
Obviously in *all* products we are aiming for individuals that will use our product and contribute *back* into the community in the form of them investing their free time or other currency hw/money/hosting etc.
JBG
Hi,
On 10/31/2013 12:55 AM, Máirín Duffy wrote:
can you maybe provide what you were specifically thinking of when you mentioned 'server community,'
On 10/31/2013 01:30 PM, "Jóhann B. Guðmundsson" wrote:
The role of server administrators
in your draft? Who were you thinking of / how would you define such a person?
Person that is active in his field but in essence you cannot apply any particular role to a community of volunteers since the role they play is what matters to *them* and what *they* decide at the moment they contribute *their free time* to it.
I think this is the point at which I can't follow. We appear to agree that being a member of the server community requires at least some experience in the role of being a server administrator. You go on to say, however, that we can't require that necessary experience for working group members because working group members are volunteers?
Or by referring to volunteers, do you mean the members of the community who aren't necessarily on the working group who are doing the work? I am not referring to that body of people at all; this section of the governance charter specifically refers to membership in the working group itself so I thought that is what we are talking about.
That seems at odds to me to say that we should have a certain number of people from the 'server community' as members of the working group, but to also say that we cannot require the experience necessary to be considered a member of the 'server community.'
How can we make sure we have a composition with the correct background to make informed decisions about what to do if we have no requirements about said background?
But certainly, I think it would help to have people who have this experience make up the majority (5) of the group because don't you need to understand about how servers are used to understand how to develop a successful server product?
Yes to develop a server product, for PRD no you dont.
I think you might have this backwards? I've been involved in the writing of multiple PRDs, many specifically for enterprise systems management software. In my experience, I've found that you do actually need to understand how servers are used to create a PRD for a server product. The PRD is essentially the blueprint for that product or feature.
You need to be a developer to develop the product and that specifically does not require experience in system administration.
How do you think the requirement would drive away potential contributors?
Simple because by doing that you are adding a barrier of entry and at the same time forming a group of elites.
We are writing on this mailing list in English. Aren't we creating a barrier of entry by requiring the ability to understand, read, and write English to participate?
( those contributors might make up them not meeting the said requirements by pure enthusiasm and the more experience would just help guide that energy into the right places )
Couldn't they take one of the four seats that doesn't require the background?
Actually after going through an PDR
Which one?
Actual there where several I went through to see the common denominator in them so I could start writing a sample draft for us to start working on.
It would be nice if we could share the specific examples to look through? There are a lot of bad PRDs out there and some good ones. Maybe we could talk about which ones we like and why and figure out what sections we think we should have based on that discussion?
PRD are very specific in their nature and function and can only be applied to a single product not community of products let alone on a community of volunteers.
We're not proposing to apply a PRD to a community of products or a community of volunteers. We've been tasked to create a PRD for a specific product: Fedora Server. Isn't that right, or am I confused?
Applying it to these 3 groups will fail in the same manner as you tried to apply it to Red Hat as a company or Fedora in whole as in making a single product out of both of these.
I don't understand why. Can you explain? Where is a PRD being applied to people instead of the specific product?
And afaik I know the other half and the presiding one required to make it work is the MRD which the community should have done first and that part has been conveniently left out by the individuals driving this.
An MRD is not required to create a PRD. It's a nice-to-have. I've proposed in another thread that, in lieu of an MRD, we develop a set of personas. It would provide us a similar kind of information. What do you think about this?
The function of the voting member is more of steering the ship then dictate the direction as in ensuring that we get from point a) to point b) and stay on course
That makes sense and sounds similar to how the Fedora Board is meant to work -
In the end of the day only thing we actually would need to vote upon ( as I see it ) is which server application we make the first product out of and that's a vote everyone should be a part of anyway.
I'm not sure, having spent 4 hours of today combing through the previous discussions on this list from the past week, that other working group members are on board with creating multiple (I believe you said 500-550?) server products out of server applications. I don't think that approach is something we have consensus on.
Would it make sense to hash this '500 product' proposal out at the next meeting? Or in a different thread perhaps?
I don't follow; can you explain a little bit more what you mean here? I don't think the server working group is pushing 3 products; isn't the server one of three products? (The three being server, cloud, workstation?) Or am I missing a reference here?
You cannot apply PRD to those product again PRD are very specific in their nature and function
In your opinion, is the current composition of the working group is temporary and just to set up the framework,
Not in my opinion afaik there is supposed to be election in January in every WG to let each group re-elect or replace the initial pointed members but maybe I misunderstood something.
Oh okay, that might be correct. I simply don't know. Can Stephen or Matt clear this one up? I don't see it written anywhere but maybe I'm looking in the wrong places. I think this is something we should make clear?
Attempting to apply PRD on a community of volunteers is rather bold move and we dont even have proper tools to do PRD and track them and their progress properly and so efficiently in the project.
What tools do you think we need?
Also, as a summary which might make this easier to follow since we're covering a lot of things not necessarily specific to the membership section of the governance charter, here's some of the loose threads I think we should take up either in other threads, in IRC, or at a meeting:
- What exactly is a PRD? What are some examples of good PRDs? What are some examples of bad PRDs? What sections does a PRD typically have? What sections do we want our PRD to have? How detailed / high-level should our PRD be?
- Do we need an MRD or would an alternative set of related data (such as Personas, which I proposed in a separate thread) be sufficient in helping us understand our target users well enough to construct a sensible / reasonable PRD?
- Is the Fedora Server one product, or is it a set of 500+ application-based products under a Fedora Server brand? (Is the latter a correct assessment of your proposal, Jóhann?)
- Is there an election planned in January to re-elect/replace all of the working group members?
- What tools are necessary to create a PRD?
~m
On Thu, Oct 31, 2013 at 8:36 PM, Máirín Duffy duffy@redhat.com wrote:
Hi,
On 10/31/2013 12:55 AM, Máirín Duffy wrote:
can you maybe provide what you were specifically thinking of when you mentioned 'server community,'
On 10/31/2013 01:30 PM, "Jóhann B. Guðmundsson" wrote:
The role of server administrators
in your draft? Who were you thinking of / how would you define such a person?
Person that is active in his field but in essence you cannot apply any particular role to a community of volunteers since the role they play is what matters to *them* and what *they* decide at the moment they contribute *their free time* to it.
I think this is the point at which I can't follow. We appear to agree that being a member of the server community requires at least some experience in the role of being a server administrator.
I'll note that this is increasingly problematic. The "good old days" when every user was a programmer (at least a shell programmer), there was not that much software to understand to manage (because disks were small and developing software was slow), and when the system was held together by shell scripts written by such users==programmers, and therefore "scratching one's itch" was both possible and obviously the correct way to design the system, are not really how the system works today.
Both system administration and software development are now vast fields with a lot of knowledge to master that make it really difficult to do well in both. So, we need people experienced with both, not system administrators exclusively.
Also, as a summary which might make this easier to follow since we're covering a lot of things not necessarily specific to the membership section of the governance charter, here's some of the loose threads I think we should take up either in other threads, in IRC, or at a meeting:
- What exactly is a PRD? What are some examples of good PRDs?
<snip similar questions>
Can we please not recurse into meta-discussions and meta-meta-discussions as a precondition to getting PRD content done? I expect the difficult part will be agreeing on the actual content; if we see a draft and decide that some parts are unnecessary or missing, we can address that at that time. Mirek
Hello, On Thu, Oct 31, 2013 at 6:30 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Not in my opinion afaik there is supposed to be election in January in every WG to let each group re-elect or replace the initial pointed members but maybe I misunderstood something.
FESCo is planning to have an election (subject to Board's approval which hasn't been given yet? I'm not following this in detail I'm afraid.) WGs haven't been given any charters by FESCo, so they are not required by FESCo to participate in those elections. Mirek
On Thu, Oct 31, 2013 at 11:27:45PM +0100, Miloslav Trmač wrote:
Not in my opinion afaik there is supposed to be election in January in every WG to let each group re-elect or replace the initial pointed members but maybe I misunderstood something.
FESCo is planning to have an election (subject to Board's approval which hasn't been given yet? I'm not following this in detail I'm afraid.) WGs haven't been given any charters by FESCo, so they are not required by FESCo to participate in those elections.
We left determining the governance up to each group, including that.
Matthew Miller (mattdm@fedoraproject.org) said:
On Thu, Oct 31, 2013 at 11:27:45PM +0100, Miloslav Trmač wrote:
Not in my opinion afaik there is supposed to be election in January in every WG to let each group re-elect or replace the initial pointed members but maybe I misunderstood something.
FESCo is planning to have an election (subject to Board's approval which hasn't been given yet? I'm not following this in detail I'm afraid.) WGs haven't been given any charters by FESCo, so they are not required by FESCo to participate in those elections.
We left determining the governance up to each group, including that.
*nod* - while FESCo may reject more outré governance models such as weekly elections or membership via random lottery, we are not putting any strict requirements on how working groups adjust their membership going forwards at this time.
Bill
Hello, On Wed, Oct 30, 2013 at 11:05 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
and pump the number of server community members to 11 or 13 ( we are going to need all those people anyway. )
My experience from FESCo is that 9 can already make it challenging to keep up with the conversation (fairly frequently the IRC discussion ends up having 2 or 3 parallel sub-threads); having more members, and having all their opinions heard within a time-limited meeting is also more of a challenge. (And, if it ever came to that, I really can't imagine a phone discussion about a complex/controversial topic in 13 people, at least not without a costly protocol to give only one person voice at a time.)
There should be just one election and that's for the server group that will replaces the initial *chosen* WG after that there should not be any other elections that's a burden we do not want in a process like this so we either do as my proposal indicates which is to have each composition group being responsabile for chosing their member to appoint to their respective seat by or the individual stepping down selects another individual to take his place or better yet the remaining members of the WG choose an individual to take that seat.
I don't think long serving terms, and especially indefinite serving terms, are healthy: there should be an easy way for the community to self-correct without requiring extraordinary effort like finding a thick-skinned "opposition leader" to set up a recall election or the like.
AFAICT unlike (Czech and US at least) national governments, the Fedora elections have always had very low overhead and basically no campaign / pre-election posturing seasons disruptive to the project; there hasn't been much burden to speak of. Mirek
Hello, On Wed, Oct 30, 2013 at 9:54 PM, Máirín Duffy duffy@redhat.com wrote:
- I would like to propose instead that we maintain a nine voting member
roster, but require that at least five of the members be able to directly represent the server community. By this, I specifically would like to require any or all of the following requirements be met by a 'server community' representative (under which all of our current 'server community' reps and other members qualify as well):
- member has worked professionally as a system administrator for a
deployment of at least 10 production servers
- member has been involved significantly as a contributor to an
enterprise Linux distribution or enterprise management product for Linux servers.
I don't think specifically these requirements are reasonable/really justifiable as written (what about 9 servers? does someone working exclusively on a specialized compiler optimization on a compiler shipped in an enterprise Android/SUSE distribution qualify?), and more generally the huge amount of effort that would be required to get this kind of requirements "right" is in itself an indication that this approach is too prescriptive: I'll gladly accept a less targeted voting body if it will give us one more month to do actual work.
And, as mentioned elsewhere in the thread, they are not really enforceable anyway.
So, to give an alternative proposal: "Active participant in the server WG" would be sufficiently targeted for me, simple enough (... and equally unenforceable). Mirek
On 10/31/2013 06:42 PM, Miloslav Trmač wrote:
So, to give an alternative proposal: "Active participant in the server WG" would be sufficiently targeted for me, simple enough (... and equally unenforceable).
+1 That seems fair to me. I think you'd have to have the experience to have the interest to actively participate anyway :)
~m
On Thu, 2013-10-31 at 18:49 -0400, Máirín Duffy wrote:
On 10/31/2013 06:42 PM, Miloslav Trmač wrote:
So, to give an alternative proposal: "Active participant in the server WG" would be sufficiently targeted for me, simple enough (... and equally unenforceable).
+1 That seems fair to me. I think you'd have to have the experience to have the interest to actively participate anyway :)
+1 let's not burden ourselves too much with rules, when we'll see the need we'll add them in due course.
Simo.
On 10/31/2013 11:19 PM, Simo Sorce wrote:
On Thu, 2013-10-31 at 18:49 -0400, Máirín Duffy wrote:
On 10/31/2013 06:42 PM, Miloslav Trmač wrote:
So, to give an alternative proposal: "Active participant in the server WG" would be sufficiently targeted for me, simple enough (... and equally unenforceable).
+1 That seems fair to me. I think you'd have to have the experience to have the interest to actively participate anyway :)
+1 let's not burden ourselves too much with rules, when we'll see the need we'll add them in due course.
+1 Let's get this over with and move to more important things
JBG
server@lists.fedoraproject.org
-
Bill Nottingham -
Jóhann B. Guðmundsson -
Matthew Miller -
Miloslav Trmač -
Máirín Duffy -
Simo Sorce