FYI, I made contact with some folks at VirtusLabs. They are hoping to respond to this discussion thread in the next little while. I will keep on top of it an communicate with to keep the ball rolling.
On Thursday, August 27, 2020 at 7:56:36 AM UTC-7 [email protected] wrote: > *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/3855fafb-5336-416b-b3ca-a78d28e37c13n%40googlegroups.com.
