Documentation about the EPEL Steering Committee are still on the wiki https://fedoraproject.org/wiki/EPEL_Steering_Committee These need to be converted over to the normal Fedora documentation.
Upon reviewing the documentation, it has been noticed that there is no formal way to get on (or off) the committee. The only mention is that they original members were the most active contributors at the time.
I would like to formalize the EPEL Steering Comittee membership. To do that, I believe we need to answer, and then document, the following questions.
Note: I am not asking to change the currently fuzzy voting format. Just formalize the committee membership.
[1] - For as long as the member wants to be on it.
When EPEL was originally set up, the 'board' was elected similarly to FESCO and other committees. I think we ended that after we had a couple of elections with fewer people running than places and the members mostly being appointed. At that point we 'joked' about the seats being life appointments and at some point we took it seriously.
Personally I would like to see a 1 year seating and elections back. If there are not enough people to fill positions, the scope and size of what EPEL can do should be lowered appropriately and the user community made aware that 'you don't show up, you don't get to choose the soup made that day.'
Metadata Update from @tdawson: - Issue tagged with: meeting
Number of Committee Members: 7
After discussions in the EPEL Steering Committee 7 seems like the right number.
Lifetime of Committee Members
There are two different ideas for this.
Lifelong - Basically as long as the person wants. Pro: Less energy dealing with changes. Pro: It's what we currently do. Con: If a person wants to step down it feels permanent since it's rare that it happens. Con: It doesn't allow much of a rotation.
Set Time - A set period of time and then some type of "election" It could be yearly. But it sounds like people are thinking of two years with staggered elections. Pro: It would allow people to step down when they are busy, and come back when they have time. Pro: It allows a rotation of people on the committee. Con: It represents a change Con: Energy/time has to be used each year to setup/do the "elections" Neutral: "Election" has to be defined. Is it a formal vote, a consensus, what.
Note: For both Lifelong or Set Time, we need to document how one would step down if the need arises.
I've started #242 to discuss formalizing the voting process.
Metadata Update from @carlwgeorge: - Issue untagged with: meeting
+1 on set time option.
Number of Committee Members: 7 After discussions in the EPEL Steering Committee 7 seems like the right number.
After more discussion at the meeting today, it was decided that 7 would be the maximum number of committee members. If there comes a time when we don't have enough people wanting to be on the committee, we can drop the number. But we should try to keep it at an odd number.
Lifetime of Committee Members There are two different ideas for this. Lifelong - Basically as long as the person wants. Pro: Less energy dealing with changes. Pro: It's what we currently do. Con: If a person wants to step down it feels permanent since it's rare that it happens. Con: It doesn't allow much of a rotation. Set Time - A set period of time and then some type of "election" It could be yearly. But it sounds like people are thinking of two years with staggered elections. Pro: It would allow people to step down when they are busy, and come back when they have time. Pro: It allows a rotation of people on the committee. Con: It represents a change Con: Energy/time has to be used each year to setup/do the "elections" Neutral: "Election" has to be defined. Is it a formal vote, a consensus, what. Note: For both Lifelong or Set Time, we need to document how one would step down if the need arises.
After discussion in this weeks meeting, it appears that we are leaning heavily towards Set Time, but we didn't feel that we should vote on it yet.
This led us to discussing how committee members would be elected. It seems there was three different ways for elections.
Election by Current Committee and/or EPEL-Packaging-SIG There wasn't too much discussion about this, but it did come up. Pro: No Ballot Box stuffing Pro: The current committee and SIG usually knows who has been doing the work. Pro: Easy to do. Con: No community involvement (short sentence, major issue) Con: Possible for the committee to become an "echo chamber"
Community Election setup by current EPEL Steering Committee I believe this was only mentioned once. Con: Ain't nobody got time for that (or something to that effect)
Community Election piggyback on Fedora Elections This had most of the discussions. Pro: A large community involvement Pro: Infrastructure and Standards already setup. Pro: Possibility to get more people involved in EPEL Pro: Possibility to get more people involved in Fedora Con: Possibility of people voting that don't know/care about EPEL Con: Possible Ballot Box Stuffing
Since voting via Fedora Elections had most of the discussion, I will point out a couple of the highlights. - It was pointed out that Fedora Elections don't have huge turnouts. That lowers the concerns about Ballot Box Stuffing, as well as people voting who don't know or care about EPEL. - We should send out announcements to epel-devel, epel-announce, and the Fedora channels about the elections.
Con: Possibility of people voting that don't know/care about EPEL
I had a followup thought about this after the meeting. Fedora elections are optional. There is a badge for participating, but it doesn't require voting in every election, just in one each cycle. So for example, if there is an election cycle with FESCo, Council, and Mindshare elections, someone could vote in the Council and Mindshare elections and skip the FESCo one for whatever reason (and still get the badge for that cycle). The same would be true for an EPEL election in the piggyback approach. Fedorans that don't feel knowledgeable about EPEL, or simply don't care about it, can skip that election and vote in the others.
This weeks discussion formalized several things.
I will take this off the meeting agenda. I will writeup a new committee page for the "new" documentation. (The non-wiki documentation)
Metadata Update from @tdawson: - Issue untagged with: meeting
Pull request with the new page is here https://pagure.io/epel/pull-request/246
After discussion in meeting and comment, and a few minor edits, the pull request has been merged. We have the new policy in place.
Metadata Update from @tdawson: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.