This issue is a follow-on to #106.
Effective organisations typically have a good sense of their role and purpose. This allows them to organise themselves more effectively, as well as evaluate their performance. It also makes it easier to onboard new members, and helps when dealing with other groups and organisations.
The workstation wiki page has a mission statement, which basically says "we make a developer-centric desktop OS". However, this doesn't answer the question of what the WG is actually for.
When documenting the WG role, we ought to describe the WG's responsibilities and powers, if it has any. We should also describe where the WG fits in relation to other groups and bodies.
Metadata Update from @catanzaro: - Issue tagged with: meeting
Should we pose these questions to both FESCo and the Council? I don't think we can answer them, as it seems like cart before the horse. The working groups were formed with Fedora Next, and it's clear there were some powers that were ceded to the working groups, as in a number of instances FESCo has deferred to the judgement of the working groups, e.g. default file system choice, and default firewall policies; not merely the package curation aspects.
What do the edition Working Groups do? What are the responsibilities and powers?
Should we pose these questions to both FESCo and the Council? I don't think we can answer them, as it seems like cart before the horse.
I was hoping that FESCo and/or the Council had already defined powers and responsibilities, and we just need to dig up the history...
But yes, if they haven't, we should ask them to do so. :smile:
I think our role and responsibility is well-understood. We're responsible for the Workstation product and can make decisions regarding that product, including decisions regarding packages included in the product. I don't think asking FESCo or Council about this is necessary or even advisable.
In relation to other groups and bodies, the Working Group is created by FESCo, so FESCo can overrule us, disband us, etc.
This: https://fedoraproject.org/wiki/Fedora.next Leads to these: https://fedoraproject.org/wiki/Workstation/Governance https://fedoraproject.org/wiki/Workstation/Workstation_PRD https://fedoraproject.org/wiki/Workstation/Technical_Specification
My understanding is FESCo created the working groups, assigned them the task of creating and implementing the Specification, and Product Requirements documents, and then signed off on those documents. This strikes me as very much delegation of tasks, where the authority comes mainly by having FESCo approve the product of those tasks. I'm not seeing anything offhand that demonstrates much actual independent auathority.
Funny enough, the very first sentence of the charter: The Fedora Workstation Working Group has nine voting members, with one member acting as the liaison to the Fedora Engineering Steering Committee.
We have 10. And I don't know who the liaison to FESCo is. I'm the one filing Council reports, which is a different and recent thing.
Another interesting item in the charter: Many of our decisions can be made through "lazy consensus".
Formal proposals are supposed to be done on the mailing list. Changing the charter requires majority vote of working group, and then approval by FESCo.
I think our role and responsibility is well-understood.
Personally speaking, I don't feel that I understand it very well, and I'm on the WG. :smiley:
And even if some people do understand the WG's role, I don't think we can assume that everyone does, without it being documented somewhere.
That documentation doesn't need to be long or complicated. Quite the opposite - short and simple is better.
We're responsible for the Workstation product and
The Workstation is made by lots of people, not just the 10 members of the WG: there are the teams on the Fedora side, like release engineering and QA, then there's FESCo and the Council, and then there's the engineering teams inside Red Hat: desktop, installer, kernel, etc etc.
Clearly we fit in there somewhere, in a way that isn't captured by just saying that we're responsible for the entire product.
Having dug into this issue, my sense is that we're supposed to be like a Workstation-specific FESCo and, as such, have the same mission but only in relation to the Workstation Edition. That could be a potentially interesting direction to take.
can make decisions regarding that product, including decisions regarding packages included in the product.
That's interesting; I haven't seen it written anywhere before (I have looked). If it is a power we have, then it would be great to document it.
I would assume that the decisions we have power over have a particular scope, since a) FESCo and the Council have greater powers than we do and b) we don't want to be involved in every small decision that gets made.
I've made some edits to the workstation wiki page, which include a description of the existing roles plaid by the WG.
I think this more or less describes the status quo. It does seem like there has been some drift between the original role envisaged for the WG and what it has become. It could be beneficial to revisit that original definition, particularly if it might help the WG to more strongly establish itself.
One area of potential development would be to define the kinds of issues that the WG has jurisdiction over - ie. which engineering changes require an OK from the WG.
Another area might be to investigate how the WG feeds its interests and requirements back to the rest of the Fedora project.
So as Chris has noticed, nobody has looked at https://fedoraproject.org/wiki/Workstation/Governance in quite a long time.
I'll prepare a proposed update of the document to correct all of the above. If approved by the WG, I'll submit it to FESCo for approval.
Since there is a proposal to switch from IRC to video meetings, I'll avoid specifying the type of meetings. I'll also try to generalize a bit so that we don't bake specifics like the frequency of meetings or the number of members we have into the governance document.
I agree with the drive for clarity in written form. I see two ways to proceed: - ask FESCo and Council for clarity as I mentioned earlier, or - alternatively, we build consensus in the working group for revised governance, produce requirement, and specification documents, as we wish them to be. And then submit them to FESCo for approval (ack/nack/patch).
I think the second option will be more effective and timely. And those documents are all due for an update anyway.
Yes, we should probably update all of the stale documents. The PRD will likely be a challenge.
Here's my start with the governance document:
== Fedora Workstation WG Governance == This document describes the governing structure for the Fedora Workstation Working Group, an independent subcommittee of FESCo. === Membership === Members of the Working Group are chosen by the Working Group as seats become available. In the event that a current member relinquishes their seat, the Working Group will fill the seat by selecting a candidate and approving by majority consensus. Eligible candidates must be in the FPCA+1 group. The Working Group is highly encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology. === Current Members === [[Workstation|View current membership]] === Making Decisions === The Working Group uses an issue tracker to propose and discuss issues, and also holds regular discussion meetings. The Working Group may make binding decisions on any matters affecting the Fedora Workstation product. Working Group decisions may be reconsidered or overruled by FESCo. The Working Group generally operates by consensus. Formal votes are not required to resolve issues except when controversy exists. For bigger issues, where there may be disagreement, or where there is long-term impact, or where an action may not easily be undone, votes may occur either in the issue tracker or during meetings. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass, with abstain votes not being included in the count. === Changing these Rules === This document will be approved by consensus of the initial Working Group members and approved by FESCo. After initial ratification, any substantive changes can be approved by majority vote and sent to FESCo for acceptance.
The PRD will likely be a challenge.
I think we can treat that as a founding charter document - just add explanation at the top to say that it's the original definition from which we take our mission.
Some other general comments about the draft document:
I think "contributions to Workstation technology" is a bit exclusionary. There are important non-technical contributions as well. Maybe amend this to say "technology and direction", or something like that.
BTW I haven't forgotten my action here (revise proposal, incorporating feedback from Allan and Matthias). But it will probably slip past the holidays.
Good idea. Proposal:
The product requirements document (PRD) and technical specifications are to be treated as a historical foundational documents, no longer effective governing documents. They are historically important and continue to inform the mission of the WG, but some parts are obsolete and they will no longer updated.
New proposal, addressing the provided feedback:
== Fedora Workstation WG Governance == This document describes the governing structure for the Fedora Workstation Working Group, an independent subcommittee of FESCo. === Membership === Members of the Working Group will be chosen by the Working Group as seats become available. In the event that a current member relinquishes their seat, the Working Group will fill the seat by selecting a candidate and approving by majority consensus. Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction. === Current Members === [[Workstation|View current membership]] === Meetings === The Working Group meets on a regular basis. Quorum is required to start a meeting. A majority of Working Group members, i.e. more than 50% of members, must be present to begin a meeting. After quorum is achieved, the meeting may continue and votes will be effective even if Working Group members leave the meeting early. The Working Group will keep records of discussions, meetings, and votes, and will make these records public to the Fedora community. Working Group shall generally be open to public observation. However, the Working Group may meet in private when necessary to discuss for sensitive issues, such as legal issues, provided that such private meetings are rare and that the public record indicates that a private meeting occurred and the general topic of the private discussion. === Making Decisions === The Working Group may make binding decisions on any matters affecting the Fedora Workstation product, including any software contained in the product. The Working Group generally operates by consensus. Formal votes are not required to resolve issues except when controversy exists. When Working Group members wish to hold a vote, voting may occur either using an online platform accessible to the Fedora community, or during meetings of the Working Group. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass, with abstain votes not being included in the count. Working Group decisions may be overruled by FESCo. === Changing these Rules === This document was originally approved by consensus of the initial Working Group members and by FESCo. Future substantive changes may be approved by majority vote and sent to FESCo for acceptance.
In Membership section: instead of "majority consensus" consider "majority of the entire membership". Consensus could mean agreement, or unanimity. Here, I think the intent is having most of the working group in agreement on new members, so just say that.
In Meeting section, 2nd line: "Quorum is required to start a meeting. A majority of Working Group members, i.e. more than 50% of members, must be present to begin a meeting. After quorum is achieved, the meeting may continue and votes will be effective even if Working Group members leave the meeting early." Consider replacing with: "A quorum, comprised of a majority of the entire membership, is required to conduct business and make binding decisions at meetings."
How about "majority consensus" -> "majority vote" to be unambiguous?
About the last sentence (After quorum is achieved...): I'm not totally certain what this does. Is it intended to permit meetings and decisions once quorum is lost? That's unconventional.
That's what Allan requested, but sure, I agree it's simpler to require quorum for everything.
Small quorums are really common and accepted practice, so I suggest defining a small quorum from the outset: 3 or 4 members. It's also valid to not define quorum in bylaws that FESCo needs to approve each time, but instead make it part of working group standing rules which can be changed by a majority vote at a meeting.
Not sure exactly what you're looking for here. But updated for your initial request to require majority quorum throughout the meeting:
== Fedora Workstation WG Governance ==
This document describes the governing structure for the Fedora Workstation Working Group, an independent subcommittee of FESCo.
=== Membership ===
Members of the Working Group will be chosen by the Working Group as seats become available. In the event that a current member relinquishes their seat, the Working Group will fill the seat by selecting a candidate and approving by majority of the Working Group membership. Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction.
=== Current Members ===
[[Workstation|View current membership]]
=== Meetings ===
The Working Group meets on a regular basis. A quorum, comprised of a majority of the Working Group, is required to conduct business and make binding decisions at meetings.
The Working Group will keep records of discussions, meetings, and votes, and will make these records public to the Fedora community. Working Group shall generally be open to public observation. However, the Working Group may meet in private when necessary to discuss for sensitive issues, such as legal issues, provided that such private meetings are rare and that the public record indicates that a private meeting occurred and the general topic of the private discussion.
=== Making Decisions ===
The Working Group may make binding decisions on any matters affecting the Fedora Workstation product, including any software contained in the product.
The Working Group generally operates by consensus. Formal votes are not required to resolve issues except when controversy exists. When Working Group members wish to hold a vote, voting may occur either using an online platform accessible to the Fedora community, or during meetings of the Working Group. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass, with abstain votes not being included in the count.
Working Group decisions may be overruled by FESCo.
=== Changing these Rules ===
This document was originally approved by consensus of the initial Working Group members and by FESCo. Future substantive changes may be approved by majority vote and sent to FESCo for acceptance.
Majority vote means more than half the votes, e.g. 9 total members means 5 for quorum, therefore 4 could abstain, and 1 vote in favor. Abstains aren't counted as votes, and all the votes are in favor which is certainly more than half. However unlikely, it's unambiguously possible.
Do you think the intent of "majority consensus" was to get agreement among the working group or just among those who vote? I think it's the former, where you want most of the members explicitly agreeing to new members, whereas it's fine to have the "majority vote" as an expedient for regular business. Perhaps it is only a formality, but I think it's nice to say that membership matters more than regular business.
Not sure exactly what you're looking for here. But updated for your initial request to require majority quorum throughout the meeting.
Sorry, the small quorum idea is offered as an alternative to having an ambiguous lower quorum after the start of the meeting. Many people are unfamiliar with it, so I threw it out there. I think it addresses Allen's concern?
Anyway, I support quorum of 3+ up to a majority of the membership. Not more than that, it gets too difficult to have meetings. However, if a small quorum, we probably also want to ensure a majority of the membership is required to accept new members. See what I mean? The small quorum is about expediency, which is good for regular meetings, but new membership should be more deliberate.
OK, changed "majority vote" -> "majority of the Working Group membership"
Metadata Update from @chrismurphy: - Issue untagged with: meeting
Proposed document, incorporates all revisions discussed to date: https://paste.gnome.org/pov4zn0ir
Legacy document: https://fedoraproject.org/wiki/Workstation/Governance
This is a complete rewrite so there's no easy way to diff it. The substantive changes reflect how the WG actually has been operating for some time, and permits the WG to make operational changes itself rather than it being explicitly written into the governing doc. Once approved by the working group, it will be submitted to FESCo for acceptance.
Metadata Update from @chrismurphy: - Issue tagged with: meeting
Thanks, this is looking good.
The draft talks about there being seats that get filled if someone leaves the group, but doesn't say how many seats there are. If we intend to have a fixed number of positions, we probably ought to say how many positions there are. Alternatively, if we want to have control over the size of the WG, we should maybe make the text reflect that, and not write that vacated seats automatically get filled.
We could state a minimum size (like "at least 9 members" or "9 or more members") or acceptable size range (like "9-12 members"), if we are concerned about too small/big.
Suggested replacement text: "To add a new member, or, if necessary to maintain a reasonably sized working group, to a replace an existing member who relinquishes their seat, the working group will identify a new candidate, to be approved by a majority of the Working Group membership."
The proposed language sets the number of seats at ten, because that's how many seats there are, and demands vacancies be filled. (How we got to ten no longer matters, it's ten.)
Alternate for minimum: The Working Group will be comprised of at least five voting members. Members of the Working Group will be chosen by the Working Group. Upon vacancies, the Working Group may fill the seat by selecting a candidate and approving by majority of the Working Group membership.
Alternate for range: The Working Group will be comprised of at least five, and not more than twelve, voting members. Members of the Working Group will be chosen by the Working Group. Upon vacancies, the Working Group may fill the seat by selecting a candidate and approving by majority of the Working Group membership.
I'm OK with all three.
My preference: A variant on the 2nd option (alternate for minimum) leaving the number blank. The WG is a FESCo subcommittee, so it's appropriate to let them decide the number.
(For brevity, I've omitted "Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction." This portion is uncontested and will remain intact.)
I don't think there's any compelling reason to specify the size of the WG in the document. I figure the less-restrictive our governing document, the easier it will be to make changes in how we operate. So I'll post a revision that incorporates Owen's suggestion. Hopefully that won't be controversial.
Members of the Working Group will be chosen by the Working Group as seats become available. To add a new member, or, if necessary to maintain a reasonably-sized working group, to a replace an existing member who relinquishes their seat, the Working Group will identify a new candidate, to be approved by a majority of the Working Group membership. Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction.
I think it's entirely likely FESCo will raise the same issue Allan has, for the same reason. The legacy document has an explicitly fixed number. If there isn't an easy way for FESCo to insert a number, I think it's likely they kick the doc back to us.
Also, my writer+editor instincts kicked in, but I did incorporate Owen's contribution.
I don't think FESCo cares how many members we have. It seems weird to say "at least five" when we know our current size is 10 and we have no intention of going down to five. Perhaps you could suggest a version that leaves the number open-ended?
Members of the Working Group are chosen by the Working Group as needed to maintain a reasonably sized working group. The Working Group may fill a seat by selecting a candidate and approving by majority of the Working Group membership.
Alrighty, sounds good.
Any further objections, please raise them now, so we can quickly approve this at the next meeting and send to FESCo!
Also proposed: "The product requirements document (PRD) and technical specifications are to be treated as a historical foundational documents, no longer effective governing documents. They are historically important and continue to inform the mission of the WG, but some parts are obsolete and they will no longer updated."
Members of the Working Group are chosen by the Working Group as needed to maintain a reasonably sized working group. The Working Group may fill a seat by selecting a candidate and approving by majority of the Working Group membership. Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction.
Complete doc, will use this same URL in the next meeting agenda. https://paste.gnome.org/px3lte8jy
(Line 1 contains 20200124T0208Z, which is the time stamp of the paste. Using is as a secondary checksum and versioning. Pretty geeky!)
We approved a modified version of this policy with the word "controversy" replaced by "disagreement." I will open a FESCo ticket to request ratification. Final text:
== Fedora Workstation WG Governance == This document describes the governing structure for the Fedora Workstation Working Group, an independent subcommittee of FESCo. === Membership === Members of the Working Group are chosen by the Working Group as needed to maintain a reasonably sized working group. The Working Group may fill a seat by selecting a candidate and approving by majority of the Working Group membership. Eligible candidates must be in the FPCA+1 group. The Working Group is encouraged to seek out candidates that have been showing persistent and high-quality contribution to Workstation technology or direction. === Current Members === [[Workstation|View current membership]] === Meetings === The Working Group meets on a regular basis. A quorum, comprised of a majority of the Working Group, is required to conduct business and make binding decisions at meetings. The Working Group will keep records of discussions, meetings, and votes, and will make these records public to the Fedora community. Working Group shall generally be open to public observation. However, the Working Group may meet in private when necessary to discuss for sensitive issues, such as legal issues, provided that such private meetings are rare and that the public record indicates that a private meeting occurred and the general topic of the private discussion. === Making Decisions === The Working Group may make binding decisions on any matters affecting the Fedora Workstation product, including any software contained in the product. The Working Group generally operates by consensus. Formal votes are not required to resolve issues except when disagreement exists. When Working Group members wish to hold a vote, voting may occur either using an online platform accessible to the Fedora community, or during meetings of the Working Group. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; a majority vote is necessary for a measure to pass, with abstain votes not being included in the count. Working Group decisions may be overruled by FESCo. === Changing these Rules === This document was originally approved by consensus of the initial Working Group members and by FESCo. Future substantive changes may be approved by majority vote and sent to FESCo for acceptance.
Metadata Update from @catanzaro: - Issue untagged with: meeting - Issue assigned to catanzaro
We forgot to ask for consensus on this point at today's meeting.
I think this should be uncontroversial, so I'll ask here on Pagure. If you don't want me to make this change to the PRD and old tech specs, please object here.
Presented to FESCo: https://pagure.io/fesco/issue/2336
The new governing document is approved by FESCo. I have updated our wiki page.
As proposed above, I've also obsoleted the product definition and technical specification, since we don't want to update these documents.
Circling back to Allan's original issue, "Document the working group role and purpose," our main wiki page currently contains the following:
The Workstation Working Group (WG) is the management and governance body for Fedora Workstation. Its roles and responsibilities include: Defining the Workstation Edition, including which software is included. Setting the Workstation's technical direction. This includes overseeing and advising on technical changes and initiatives. Creating and tracking engineering initiatives, as necessary. Acting as a point of contact for Workstation design and engineering issues. Coordination and liaison with other Fedora teams and organizations. The WG was created by (and is ultimately responsible to) the Fedora Engineering Steering Committee (FESCo).
The Workstation Working Group (WG) is the management and governance body for Fedora Workstation. Its roles and responsibilities include:
@aday, do you want any further changes or clarifications here? Or can we close this issue?
Circling back to Allan's original issue, "Document the working group role and purpose," our main wiki page currently contains the following: The Workstation Working Group (WG) is the management and governance body for Fedora Workstation. Its roles and responsibilities include: Defining the Workstation Edition, including which software is included. Setting the Workstation's technical direction. This includes overseeing and advising on technical changes and initiatives. Creating and tracking engineering initiatives, as necessary. Acting as a point of contact for Workstation design and engineering issues. Coordination and liaison with other Fedora teams and organizations. The WG was created by (and is ultimately responsible to) the Fedora Engineering Steering Committee (FESCo). @aday, do you want any further changes or clarifications here? Or can we close this issue?
Defining the Workstation Edition, including which software is included. Setting the Workstation's technical direction. This includes overseeing and advising on technical changes and initiatives. Creating and tracking engineering initiatives, as necessary. Acting as a point of contact for Workstation design and engineering issues. Coordination and liaison with other Fedora teams and organizations. The WG was created by (and is ultimately responsible to) the Fedora Engineering Steering Committee (FESCo).
I think that's text that I added. I'm sure it could be better, but it seems OK to me too.
Since you don't have any further requests, I'm going to close this issue. Thanks for pushing to improve our defining documents!
Metadata Update from @catanzaro: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.