Ticket #1177 (closed general: fixed)

Opened 17 months ago

Last modified 17 months ago

Codify how we are going to select the working group members

Reported by: sgallagh Owned by:
Priority: major Keywords: meeting
Cc: Blocked By:



We need to publicly decide how we are going to select the official membership of the working groups for the Fedora.Next/Products? implementation.


We want to be completely transparent about how this selection is taking place.



  1. Each working group should consist of an odd number of members not to exceed nine (to keep the groups small enough to be functional)
  2. Each working group should be comprised of no more than half (rounded up) of Red Hat employees. This is to avoid the misconception that Red Hat is dictating the planning here.
  3. No one should be selected to be on two working groups. The time commitment will likely be too much. We should encourage people who have volunteered for multiple groups to instead volunteer for the Common Base group.


We should set up range voting for each of the working groups and request that ONLY volunteers for those groups vote. In this way, FESCo can see a self-selected view of how the membership feels it should be made up. This will guide the decision more clearly and make it less of a FESCo-dictated decision. The final selection should be consistent with the above rules unless this is clearly impossible, in which case FESCo should use its best judgement.

Change History

comment:1 Changed 17 months ago by kevin

FYI, our voting system can only restrict who can vote by fas group. So, if we wanted to enforce only voting from candidates we would have to add each pool to it's own group. Or use the honor system.

comment:2 Changed 17 months ago by toshio

Or have an admin verify that only candidates voted in the election. (In which case, we'd want to be explicit that that would be happening.)

comment:3 Changed 17 months ago by mattdm

I would like to, where possible, make sure that each group has members that work on or with several of the important existing functional Fedora teams: QA, Rel-Eng, Ambassadors, Marketing, and so on. For example, if only one person signed up saying "I want to work on QA for this", that person should have preference.

If we need to ask people for more detail along those lines, we should.

comment:4 Changed 17 months ago by toshio

As I think about how to accomplish changes within Fedora... I'm not sure that I would go with this plan and criteria. Rather, if FESCo has a vision for what Fedora.next should look like, FESCo should take the pool of candidates and select those that are best able to achieve that vision. This would be more like a hiring process than an election of officials. OTOH, if FESCo doesn't have that vision, then it could be appropriate for a more self-selected group to be chosen and then for them to tell FESCo what they want to implement. My impression has been that FESCo members have a vision for where they want us to go so I'm currently leaning away from an elected process. Other thoughts on whether my premise is incorrect?

Couple problems with FESCo selection though:

  • Does fesco know the candidates well enough to decide if they're appropriate to implement our vision? Would we need to take time to do interviews?
  • How would we do the actual logistics of deciding which candidates fill the open spots? mattdm mentioned that he wouldn't want us to end up in a fesco meeting going through the lists person by person. If we were to make the selection we'd probably need to make our lists ahead of time and coordinate it so that if there were some people who were obvious front-runners and some people that were obviously not going to make the cut we could eliminate them and just concentrate on the candidates in the middle that were contentious. And then we'd still need to set aside a fair chunk of time to figure out the remaining spots.

comment:5 Changed 17 months ago by mitr

  • Resolution set to fixed
  • Status changed from new to closed

From the 2013-10-02 meeting:

Agreed(+7): Assign a FESCo member to each WG. This member is part of the WG, and they will select the initial 9 members (approved by FESCo). Succession planning and governance is a deliverable *of* the WG.

Agreed(+5): WG nomination period will end on Oct 14 0:00 UTC.

Note: See TracTickets for help on using tickets.