Hello, Thanks a lot to Virtus Lab for the response! I hope we could revive this discussion, all interested parties are welcome to participate.
For the record, last week there was a hosting request from Red hat for starting the new operator: https://groups.google.com/g/jenkinsci-dev/c/oAWCXDbgcG4 . This request has been approved by the community, hence right now we may end up in a situation when there are 2 operators and a community split between them. Best regards, Oleg On Wednesday, November 18, 2020 at 4:54:38 PM UTC+1 [email protected] wrote: > Hi all > > Quick introduction - I am CTO of VirtusLab, original company behind > Jenkins Kubernetes Operator. > > ------ > > First of all, apologies for prolonged time it took us to get back to this. > > To the point - *it is definitely useful and desirable to have well > understood governance rules* (and thanks Akram for submitting this draft > proposal ð ). Details might need to be discussed but this is definitely > good starting point. > > To give you a little bit of background: > Out step back from the project (in fact not a step back, rather rethinking > first principles) resulted due to our internal work related very much to > Jenkins Kubernetes Operator. We wanted to put some public work on hold > until we have this sorted out. We were hoping for the work to be concluded > in Oct, but (as is often the case with software development) we got some > delays and currently aiming at having work concluded next week. > > *We definitely see a case for cooperation and making Jenkins Kubernetes > Operator more popular e.g. in environments like Open Shift.* (which I > believe is main point of interest for Red Hat). That said I think it is > very much justified to say that the overwhelming majority of work done on > this project (original author and overwhelmingly major developer efforts > including majority of bug fixes ) comes from our organisation and we felt > we have a little bit more right to steer the direction of the evolution of > the operator project. We definitely see that doing work that would help > Jenkins Operator be more usable e.g. in Open Shift is valuable, in the same > time however this cannot be done by sacrificing the overall direction (we > have more cases than only this one!). > > We do however understand that to have Jenkins Operator being more > collaborative project we need to communicate our intention better to make > sure everyone is on the same page. To that end we are going to work in > following areas in upcoming weeks: > > - public roadmap for the project > - contribution / governance model (which can be very much based on > your suggestion) > - separation of specific area - e.g. Open Shift is much more important > for Red Hat than us and we should be able to separate this area a little > bit to make Red Hat contributor's work more streamlined. > > As for the timeframes: > > - we are working on these things *right now* > - we aim at being ready *s**ome time in December* (given holidays etc > - it would need to be 1st part of the month). > > Once again - I really appreciate the governance proposal you suggested ð > I think it is very much in line with our thinking and I have zero doubts we > would be able to come up with version that would feel satisfactory for all > the sides (+future contributors). > > I hope this sounds reasonable (if not - don't hesitate to let me know, > happy to discuss more details!) > > > On Wednesday, October 21, 2020 at 1:28:28 AM UTC+2 slide wrote: > >> 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. >>> >>> > Email correspondence is considered personal data processing. Check out our > Privacy > Policy <https://virtuslab.com/gdpr> for details about the controller of > your data and your rights according to GDPR/RODO. -- 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/060e8503-dbcc-4763-b887-e0bfb4974360n%40googlegroups.com.
