*Background*
In mid-october 2019, Jenkins on OpenShift developers team from Red Hat
started to engage in the jenkinsci/kubernetes-operator
<http://github.com/jenkinsci/kubernetes-operator> (aka Jenkins Operator) as
contributors and committers. The initiators of the project are contributors
from VirtusLab company.
After a few commits related to documentation and minor bug fixes, the
team, backed by product management, expressed their wish to engage more in
the community and the project.
To facilitate communication and collaboration, several rituals has been
put in place by Red Hat team members:
-
Subscribing to the slack channel on virtuslab's instance and providing
best effort community support to the users who were asking.
-
Scheduling a developer call each week to discuss developer related
issues and ways to improve the software. Several additional stakeholders
from Red Hat, who were strongly interested in extending Jenkins features
were able to join (to name a few, J.F, R. Crisp, S. Bose, ....)
-
A weekly community call to allow users to talk about their use of the
plugin and features they would like to see. If not enough users were
joining, which was often the case, this call was used to discuss
architecture and development topics.
After months, discrepancies arose, especially regarding architecture and
design. At the same time, contributing features was harder both for
technical reasons (monolithic operator) and for governance reasons (Red Hat
developers didn't have commit permissions).
Despite these difficulties, Red Hat management insisted in remaining
engaged in a community based operator and to continue the contributions,
and also engage in larger refactoring tasks. Red Hat committers asked
several times to have commit permissions. Initially, these requests have
been rejected by invoking the will to keep control on the code quality.
After several months of discussions, and difficult collaboration, Red Hat
team members engagement was constant but commit permissions were still
refused.
Then, during a period of around 2 months and related to personal reasons,
the main committer was not able to validate PRs, nor letting the other
contributors be able to do it. The project was and is almost frozen.
Red Hat is escalating the discussion to the Jenkins CI board to see how to
solve this issue. As it was discussed as there is no existing process in
place for transferring permissions when a component maintainer explicitly
rejects that. Red Hat is asking to set up a governance that complies with
the Jenkins Code of Conduct and allows Open Source friendly collaboration.
*Governance revision proposal*
The proposed governance has a main objective to ensure permanently that a
distribution of the commit rights across the active stakeholders of the
project always exists. The definition of "active stakeholder" can be
defined more accurately by the project board. But, as an initial proposal,
an active stakeholder can be defined as:
"An entity contributing to the project in any form within the last 3 months
would be by submitting code, committing code, proposing PRs and
documentation or participating actively on a regular basis in the community
calls".
We can add to this group any active user who can submit a minimum amount of
documented and reproducible issues.
Initial working group leaders are defined using the following requirements:
-
Initial leadership group consists of 3 or 5 members
-
Founding parties: Virtus Lab, Red Hat, Jenkins Governance Board
-
Each party nominates a representative
-
Domination prevention: there should be no party having more than 50% of
working group members.
The governance charter needs to define a few engagements and entities:
-
Scope of rights and responsibilities explicitly held by the committee
-
Committee structure that meets the requirements above
-
Election process, including:
-
special elections in the case someone resigns or is impeached
-
who is eligible to nominate candidates and how
-
who is eligible to run as a candidate
-
Voter registration and requirements
-
election mechanics such as
-
committee company representation quotas
-
Limits on electioneering
-
Responses to election fraud
-
How are changes to the charter enacted, and by what process
-
How are meetings conducted
-
Recorded or not, and if not, how is the information shared
-
How is work tracked? Example steering project board
-
Is there a member note taker, or is there a neutral facilitator
role that exists outside of the committee?
-
Frequency, duration, and required consistency
-
Committee decision-making process, and specifically those areas of
action that require more/less consensus, e.g. modifications the charter
*Contribution Process*
-
The active stakeholders of the project engage in getting members from
the contributor/user community to form a working group to drive the
direction of the project.
-
Explains to potential contributors how/if they can add code to the
repository/repositories
-
Documents Workflow and management of pull requests
-
Identifies who is authorized to commit or revert code
-
Identifies automation is required for normal operations
-
Defines how release decisions are made
-
Who is authorized to release and when.
-
Frequency limits
-
Defines the documentation process
-
Defines what CLA process is required and how it is programmatically
enforced before code is merged.
*Project Communication Channels*
-
The working group is added as an official entity of the Jenkins
community. E.g. as a sub-project until the jenkins.io terminology is
updated: http://jenkins.io/projects
-
The working group initially includes two roles: leader and member
-
Jenkins Operator project meetings are considered to be the main
communication and decision making channel
-
The decisions are made by a consensus among contributors
-
If a consensus cannot be reached, a voting between the working group
leadership takes place. The decision is achieved by plain majority.
-
If a decision cannot be reached on the working group level, the
Jenkins Project decision making process is used:
https://www.jenkins.io/project/governance/#meeting
*Permissions and access*
TBD
*Issues and questions*
The following questions and issues are not answered yet and have to be
answered before the establishing the governance chart:
-
Can a contributor lose its status? Permanently or temporarily ?
-
How can newcomers be promoted to leaders or contributors roles and with
which frequency ?
-
What happens if an organization gets disengaged from the community ?
-
What if no quorum nor consensus or majority can be reached for some
decisions ?
-
What are the permissions and accesses given to a maintainer and what are
the different roles maintainers can have. Eg: CI Cop, Release Cop etc.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/4d6366d5-0e8f-4e53-9c0d-e130a3169d89n%40googlegroups.com.
