Establish RFC process #1
Conversation
|
looks great. thank you for creating a repo specific to tracking these discussions, it will be a million times easier to keep myself involved in things as they come in. 👍 |
| development team. As project creator, [Thomas | ||
| Hatch](https://github.com/thatch45) will have a final veto on any RFC. | ||
|
|
||
| ### 3. Acceptance / Rejection |
There was a problem hiding this comment.
Should rejected RFCs be put into their own folder so that they aren't intermingled with other RFCs?
There was a problem hiding this comment.
@DWSR We've discussed both sides of the coin. (also, rejected RFCs will be merged, so we can use them later to point to and say, "No, we're not doing that because it's already been proposed" - basically taking a page from the PEP process, rejected PEPs are still PEPs)
I believe we've talked about simply maintaining a .md file here in the repo with a list of "accepted" and "rejected" RFCs. Then one can see at a glance what RFCs even exist, just by scrolling through the file list here on GitHub. Even if we hit 1,000 RFCs, it still shouldn't be awful to scroll through.
What's your scenario scenario/thought behind sticking them in their own folder?
There was a problem hiding this comment.
Sticking rejected RFCs in their own folder makes them a little less visible than accepted RFCs, but maintaining a TOC is a good compromise, I think.
I would love to see a static site though
So what do you propose would work better? Because I don't see a good counter proposal here yet - do you think that we should wait for 6 months if there's any kind of disagreement? That sounds like a great way to go nowhere, while alternatives to Salt are moving forward. Another point to consider: note that the wording here says:
Not acceptance, just veto. For the reason that you mentioned. What healthy discussion can you point to that has taken 6 months? I fully expect that most RFCs will take less than two weeks to suss out everything that needs to be discussed, and at the end of that time it should be fairly trivial to make a yes or no decision. Also consider the fact that it's trivial to develop ones own Python packages, and because Salt is written in Python if one disagrees with the decision to reject an RFC, it's totally possible to write code and install it along side salt and go ahead and use it from within salt. Do you disagree with any of those points? |
|
I have to agree (mostly) with @isbm here. IMHO, it would lead to a more engaged community, a better review process, and a stronger overall project if a CAB were established which participated in votes on RFC acceptance. |
|
@cachedout @isbm I disagree here that the community should have a voting mechanism because Saltstack is a private for profit company with paying customers. It is not the CNCF or Linux Foundation, which are NFP. I think the community engagement should be the comment period itself and that maintainers should ultimately be the ones making the decisions. It is their responsibility to listen to their customers, which includes but is not limited to the community. |
|
@DWSR IMHO, the goals of a correctly structured community governance model and a for-profit company should not be orthogonal. To wit, I would point out that plenty of for-profit companies -- even those which are mainstays in the automation space, maintain both a BDFL and a community governance board with voting power, as well as accepting core maintainers which are not employed by company. For example: https://github.com/chef/chef/blob/master/MAINTAINERS.md (I do not know the current state of Chef's CAB and only see an indication in another RFC that they are going to establish one but I'm not sure if that happened.) Though, while I'm on the topic, I would also encourage those interested in this project to read Adam's excellent set of essays on this topic: Specifically, I would call out Adam's point where he -- in my view, correctly -- identifies technical communities as having both a strong executive and a strong community advisory board which co-exist and provide balance to each other: https://sfosc.org/sfosc-book/governance/ |
|
Hey, thanks for your response! From what I understand, the goals behind the RFC processes are:
Driving community engagement is a good thing - healthy communities are a good thing, and Salt is definitely into a healthy community!
Sure - nothing is stopping anyone from doing that. But that's not a free choice. SaltStack devotes a lot of resources in terms of manpower to developing Salt. If one decides they want to fork Salt they are losing those resources. Meanwhile, development on Salt continues, at a higher velocity and a higher rate of adoption because it's continuing to improve. My understanding is that the goal of this RFC process is not to please everyone. It's to help those of us who are interested in making Salt awesome continue to make Salt awesome. Arguments only contribute so much towards making Salt awesome, and every single choice will have some sort of impact and tradeoff. Do we use RFCs, or does SaltStack simply do as they please? Do we go with feature X or feature Y? Do we support the last N releases, or are they abandoned when they're released and just have a rolling release schedule? Personally, it doesn't matter to me who is making decisions, only that there is a clear, definitive body that's making decisions and directing the project. Are there decisions that Tom has made that I don't agree with? Sure! But I'm also haven't built an incredible piece of software that's used by (tens of? hundreds of?) thousands of people and I haven't significantly helped build a company, so I don't have that experience and maybe my initial impressions are wrong. So I'm fine trusting his judgement, especially if I don't have any solid experience or data to the contrary. And I trust that Tom probably won't abuse his veto powers, because as you point out - if the community doesn't trust that SaltStack has a vested interest in making Salt the best software it can be, they can always fork the project and move on. But from what I've seen of Tom, and the rest of the SaltStack team - they're united behind the goal of making sure that Salt is (stays, really 😉 ) the best automation platform out there. If I'm operating from that assumption, and I made the same assumption about you, if we're all provided the same information there should be no difference in the decisions that you or I or Tom makes - we would all make the choice that makes Salt the best project that it possibly can be. So what's wrong with giving RFC veto power to someone who:
As for RFC approval, kind of the same thing goes. Why not give approval to people who are invested personally and professionally in making Salt the best product it can be. Aside from whatever family obligations we have there's literally no conflict of interest here. On the other hand, if we require approval from some kind of community board, each member of that board will represent different interests that may or may not conflict with making Salt the best product that it can be. Not only that, but it's literally not their job to make sure that Salt is awesome - that's just something that they're doing for fun. If they get tired, or bored, or they have prior professional commitments, Salt suffers. You've given a couple of alternative ideas and examples, but I'm still not clear on how they would be better at making Salt better? What is it that those proposals offer that we can't or won't get from the existing RFC? |
|
Hi @waynew. I’m hopeful that this wasn’t your intention and simply unfortunate phrasing, but this sounds a bit like the argument that you’re making is that SaltStack's employees have de facto claim on the project's best interest while its users and contributors may not. This would be, to put it mildly, an unconventional view on FOSS governance and one that I would contest vigorously. The fact of the matter is that for-profit companies which sponsor projects absolutely have incentives which may not be in the best interest of the project and if you would like specific examples, I would be more than happy to provide them to you privately, as I don’t think they’re appropriate to discuss publicly. That said, I would again point back to my previous point where I make the point that a strong executive balanced by an advisory board which is responsible for ensuring a transparent process does, in fact, address the bulk of these concerns, while maintaining the ability for a BDFL to veto decisions in what (one would hope) would be the rarest of cases. |
|
These are all very good points, and the main point of balance I want to make is this one: https://hub.packtpub.com/why-guido-van-rossum-quit/ My main question here is that I want to make a process that allows decisions to be made without the kind of fighting that makes leading and participating in a community so difficult that those asked to lead and those on the core team have to have community fights every time they want to get work done. My main concern here is not the perfect representation of SaltStack the company as much as the creation of a process that does not place undue load and pain on the core maintainers of the project. |
No - and of course people are complex creatures that are totally capable of acting against their best interests, including when they sacrifice for the good of the community 👍 |
|
@isbm and team, I am reading all of the points you have made here and as much as I hate to jump in.....I have never had any issues with the decisions made by Salt's team or @thatch45 and I personally (FWIW) have zero issues with Tom's right to veto and actually 100% support it. The resources that Tom and team pump into this project are priceless and in my mind that gives them every right. Honestly I think we as a community forget what it would be like to be in the founder's shoes and get blinded by our views/wants/etc. All that said, I see a ton of hypotheticals here and nearly no actual use cases where @thatch45 has done something to undermine what the community wanted and needed. Aka...this seems like a waste of bits on the wire to me #oneMansOpinion |
|
(Edit: I would like to clarify that this statement was made in response to comments which have since been deleted by isbm) Thanks @ablinkinz, the more I read the comments the more I feel like this is a personal attack. I have listened to the community and have worked hard to work with them. I also agree with @waynew on may points, I have seen how large multi corporation communities are run and I often see serious conflicts. I also want to point out that there is a difference between community and corporate interests. In these large democratic communities they are almost always driven by competing corporate interests. One of the main reasons I have held onto control over the years was not only to protect SaltStack the company's interests, but also to work to protect the community interests. I would also like to point out that the present proposal and the composition of Salt's community would almost certainly lead to a multi corporate controlled project. Also, and disturbingly, this has become very personal, and the attacks have started to become focused directly on me. I cannot please everyone, but I do think I have acted in good faith. I think that I can easily defend my rights to maintain the head and direction of Salt. I did create this project in my basement and burned all of my savings getting it off the ground. I have worked very hard to create a company and a revenue model so that Salt can be maintained. I still can hold claim to having designed, architected and personally developed nearly all of the major features of Salt. From a design and management perspective I have been working on Salt continually despite not being as visible in the community over the last few years. We have given contributors ownership and control over their code, we have merged and accepted features and worked with community members. We do not hold back from merging community members' code to maintain their contributions, but we do review their code. Because despite the intentions of the contributor, and despite how much power we give them, contributors come and go. Finally, I do not want the RFC process to be about approvals, but about comments and collaboration. But @isbm , you have made your hand here very clear. You want control, and you want to be able to prevent me from moving the project forward. You have also issued many threats, of forks and of using other projects. I am also aware of the fact that you have already started creating a competing project to Salt, which places you in a clear conflict of interests. I have to wonder if you are actually working to sabotage Salt in favor of your new project. Your actions, aggression and open violence towards me, Salt and members of the community would make me very hesitant to place you in a position of authority. |
|
some thoughts on the past few comments, sorry if its a bit rambling: On the other hand, @isbm does also make some valid points about the longer term work and goals being done with salt-open not being done in the open. The inability for the community to be involved in one particular important piece of work/decision was the python2-python3 decision. I don't really have a good solution in the way of a written document/process to follow, but my thoughts basically boil down to 'it'd be great if the community and salt co try to reach consensus'. Perhaps there is middle ground that with some compromise makes everyone happy? Although I think in general having a fleshed out RFC process is good, I am fairly sure we won't see this amount of fervor on the next 50 RFC's - the python 2 handling is specifically a point of contention. If we can reach consensus on that I think this won't really be that big an issue going forward. |
|
And on the python 2 point I completely agree. While I was aggressive in presenting the python2 drop I did rescind and rewrite it when complaints were presented. I also worked hard to present an RFC with the requested proposed data, and alternatives. This RFC has been created in direct response to the fact that after 1 week and with no comments on the python2 drop we merged it. Upon complaints we reverted the merge and opened this RFC so as to better create an environment for better discussion. In the process though I have been personally accused of all manner of nefarious intent (primarily from isbm) when in fact I have listened, modified and worked with criticisms. It is because I want consensus that I have opened the RFC process up more, but I do not want to make major leaps in the project governance too quickly. |
Here is what I will say as someone who recently left the core team but still While code is merged from the community, it does not feel like we have a sense I still know most of the core engineering team. I believe y'all are doing what I do not have a competing project, and I don't have any desire to make one. If you decided to add a CAB I would love to be apart of that process. But in the |
|
I think a lot of this animosity is the unfortunate side-effect of misunderstanding-- misunderstanding that this process aims to clear up. The original Python 2 deprecation PR was withdrawn because of the valid objections that were raised by the community, as well as internal disagreements over the timeframe of the change. I personally was not aware of the second PR until after it was merged, but as someone who was part of the internal discussions regarding considerations like the unsolved salt-ssh issues that currently block such a deprecation, I can assure you all that these issues have not been forgotten. That they were not properly enumerated in the second PR, and that the PR was prematurely merged, were mistakes. The assumption was that we would add details regarding the outstanding issues to the RFC at a later date, but this also was not properly communicated, leaving others to come to their own conclusions. We understand this, and the fact that we are taking steps to more clearly enumerate this process (so that we can come to an unambiguous RFC regarding the deprecation of Python 2) should be a clear indicator that we are aware of the past failures in communication, and are making a good-faith effort to rectify them. It should be noted that even this RFC process document is subject to comment and modification. If we wanted a unilateral RFC process, we would have just pushed this changeset instead of opening a pull request. @cachedout's suggestions in particular are well-spoken and worth consideration. In the meetings where we discussed this RFC process, we did discuss that the community needed to be involved in the process. We were hoping to figure out what shape that would take in this comment thread. I am definitely in support of a CAB and in my opinion I think we need to shift the discussion to how such a group is to be formed and what role they will have. For my part, I don't think it's unreasonable or controversial to say that allowing the CAB to have control of the project's direction is a bad idea. The community is an invaluable resource; they provide perspectives we do not have, and are an important check on the project doing things that have consequences that haven't been considered. But in the many years I've been a core developer I've encountered my fair share of community members who, while intelligent (and sometimes quite passionate in their opinions), did not know Salt well enough to know that what they were proposing was a bad idea. While it is likely that cooler heads would prevail (despite what the comments in this thread have thus far suggested), I think the final decision must rest with the project's core development team. I'm confident enough in this team to trust that if the community disagrees or raises valid concerns, they will be heard. Were that not the case, we wouldn't be having this discussion right now and would have proceeded with the original plan (one which, full disclosure, I disagreed with). |
|
Hi friends! Well, this went a bit off the rails, didn't it? :) Communities and maintainers who care about the same thing very much sometimes disagree and that's just fine. What matters, of course, is that we can work through it and come together in the end for a stronger community and, with any luck, as better friends. The Salt community as well as Tom and everybody at SaltStack have brought me so much knowledge, opportunity, and joy over the years that now seems like as good as time as any to personally thank each of you. ❤️ Now, on to the business at hand. To Tom's point about not wanting to rush into a governance proposal, I understand and agree. However, I do think that it may be unwise not to take this moment where we're all interested in the outcome and in one place to set forward a proposal in the hopes that it can be used as the framework for a process which makes everybody happy. To respond to an earlier reference, I like Aesop as much as the next person, but I've always thought that the lesson of that fable was not that none could be pleased, but instead that we undermine our individual goals when we refuse to share our burdens with each other in the spirit of equanimity. So, with that thought out of the way, allow me a proposal and if it should be moved to another thread or means of discussion, I'll defer to the Salt maintainers to decide. In short, I think that much of what needs to be achieved here could easily be done so through the formation of an RFC Review Team that would consist of a balance of community members and Salt employees or customers. The community side could be elected through a process that ought not to be too hard to enact. The team could meet every couple of weeks in an open meeting held via videoconference which is announced well in advance. Anybody not formally on the RFC Review Team who wishes to would be welcome to join would, of course, be welcome. Agendas would typically be to review open RFCs and to provide comments and discussion. For RFCs ready for a vote, members could vote. The BDFL could, as discussed, veto any decision though this would likely be quite rare. Meeting minutes and and video archives could be made available to those who could not attend. Ultimately, I think this would solve the biggest underlying pain point here which is that one could easily imagine how an IC from the community might feel disenfranchised when a decision is made without understanding why or how. At the same time, the core team wants to preserve their ability to maintain control of the project which is, as @terminalmage pointed out, a completely reasonable desire. Everybody can be heard, we can bring formally closed-door discussions into the open, and hopefully, emerge with stronger solutions that we might otherwise. Ultimately, framing this discussion as a question of control is very much a red herring. There is undoubtedly a solution that can be constructed which makes everybody feel heard, provides a forum for discussion and improvement while maximizing transparency throughout. These, along with compassion, understanding, intellect, passion and skill are the ingredients for a successful community. Hopefully we can come together in that spirit and find a collaborative framework that's just, respectful, open, and fair. Your friendly maintainer alumnus, |
|
@cachedout well articulated and i'm very much in support of what you are suggesting. @thatch45 I can only image the pressure(s) one faces when managing two very different stakeholders: the community at large (users and contributors) and investors. Although there are bottom lines to be addressed, there are also those that share the same passion for the project (include me in that list :D ). Formalizing a decision process that grants the community a collective voice (through @cachedout's suggestion) feels like the right path for contributors and users. I have a strong interested in being a part of that process. Secondly, I don't think anyone here could argue your lack of passion and commitment to the project and the company. However, I do believe there are people out there which will not agree with you. They may seem like personal attacks on the surface but are really rooted in misunderstanding and frustration. I can only encourage you to not engage in those feelings. Take those situations for opportunities to understand another point of view no matter how fruity the language may appear. Each conflict is growth. @waynew just a few points I wanted to talk through.
There will always be differences of opinion and interest. But to say that the community will hinder the ability to come together on a proposal seems misguided to me. Diversity in the audience prompts growth and thought. Making decisions in a vacuum distances the core team from the users needs. In other words, if the product can not meet my expectations, I move to another product. If the core team is not listening to and working with the community, it becomes very hard to grow the user base.
Salt is extremely important to me. The success of the product directly correlates to the success of my current position. In other words, If salt fails I fail. So to say I am doing this for fun is again misguided. Every member of the CAB will have prior professional commitments. I like surfboards and I need money to buy new surfboards :D . And in the event that someone does leave the CAB, I assure there will be someone waiting to take that seat. again this is with the conjecture that the CAB concept is actualized |
|
btw, this is one heck of a first PR for salt-rfc |
|
This has turned into a very lively debate, which is what you would expect (and want) from people who are passionate about a topic. This is what we want to see from the RFC process (maybe a little more on topic at times) so that we can surface the issues in the community and bring them to a fruitful discussion. I would like to bring this back to the main goal of the RFC process which as stated in the document is:
As many have pointed out the need to formalize the RFC process was highlighted with the Python 2 – Python 3 discussion earlier in the month. Our goal with this RFC process is to facilitate more discussion and feedback in the design phase so that we can come to that consensus and enable the community to build the best project possible without fits and starts. Many have commented in the last 12 hours about how we are currently debating the governance aspect of this RFC, which while important is not the crucial aspect of wanting to implement an RFC process, the crucial aspect was to have a better and more transparent review and feedback process. Governance is an important topic and one that will not be hashed out in a side conversation about the RFC process, rather it needs direct attention and should evolve in an iterative process as the community evolves. As @terminalmage pointed out this is a starting point, a living process that will grow and refine over time as the needs of the community evolve. The document itself states:
I see this RFC proposal as a great step in the right direction, one that we should progress forward so that we can have a starting point to formally facilitate discussion and exchanging of ideas as it relates to key features. We should also note the need for a discussion around governance and community engagement as one of the key areas of this process that needs further refinement and enhancement. I’m asking the interested parties to look at the mechanics of this proposal and provide feedback on if it will help enable them to have more insight and better mechanisms to work with the core team to improve Salt and ensure concerns and complaints are surfaced and addressed before development begins, and if not where can that be improved so that we can establish this starting point. Then allow us to use this process to elicit feedback on other important matters of the project as well as the process. |
There was a problem hiding this comment.
This RFC process looks great except for one mechanic I would like to discuss, I think there this would be a better option for deciding how RFCs get accepted.
I’m asking the interested parties to look at the mechanics of this proposal and provide feedback on if it will help enable them to have more insight and better mechanisms to work with the core team to improve Salt and ensure concerns and complaints are surfaced and addressed before development begins, and if not where can that be improved so that we can establish this starting point. Then allow us to use this process to elicit feedback on other important matters of the project as well as the process.
| the **Final Comment** period, a decision will be made on whether or not to | ||
| accept the RFC. Acceptance requires approval from five (5) members of the core | ||
| development team. As project creator, [Thomas | ||
| Hatch](https://github.com/thatch45) will have a final veto on any RFC. |
There was a problem hiding this comment.
For the mechanics of the proposal, I would like to propose that we discuss an alternative to how RFCs get accepted.
In short, I think that much of what needs to be achieved here could easily be done so through the formation of an RFC Review Team that would consist of a balance of community members and Salt employees or customers. The community side could be elected through a process that ought not to be too hard to enact.
The team could meet every couple of weeks in an open meeting held via videoconference which is announced well in advance. Anybody not formally on the RFC Review Team who wishes to would be welcome to join would, of course, be welcome.
Agendas would typically be to review open RFCs and to provide comments and discussion. For RFCs ready for a vote, members could vote. The BDFL could, as discussed, veto any decision though this would likely be quite rare.
Meeting minutes and and video archives could be made available to those who could not attend.
There was a problem hiding this comment.
I think I'd like to see the current proposal to through a couple of PRs before requiring a synchronous process.
Salt, being a world wide community, has interested parties across time zones.
As it is, discussion already can happen in the open on PRs - if we feel the need to summarize discussion points, that can happen on the PR. The only thing we might lose is the face-to-face nature of the teleconference.
I do prefer face-to-face interactions for some things (there's a reason there's a language summit during pycons), but I'm not sure if it's the best choice for typical RFCs.
Do you have some experience using video conferencing for reviews, or some other thoughts about why it would be better than the asynchronous style proposed?
There was a problem hiding this comment.
Hi @waynew. I took a brief swing through some popular projects to find a couple of quick examples for you:
https://github.com/helm/helm
Developer Call: Thursdays at 9:30-10:00 Pacific. https://zoom.us/j/696660622
Jaeger tracing
https://www.jaegertracing.io/get-in-touch/#bi-weekly-project-meetings
Envoy:
https://github.com/envoyproxy/envoy#community-meeting
I honestly just grabbed three projects totally at random from the CNCF page but there are many others.
|
I would like to thank everyone for comments here and I think that we have an excellent opportunity to build a better community and a better process around accepting changes and updates in Salt. In going over this proposal I have spent a lot of time talking to others who have set up like communities as well as reviewing the comments here. As such I would like to propose a number of changes here in the next few days and weeks that hopefully reflect better community involvement and voice, as well as a path forward to get these decisions laid out. I agree that having a CAB would be a wonderful thing, and that we need to involve the community in the vetting process more deeply. Many of the needed changes and agreements will take quite some time to hammer out, but I feel they also should be set up in proposals, this process will take time to build out and should not be rushed. In closing, I would like to admit that I am still quite emotionally drained, the stress of these proceedings has left me with little sleep over the last few days and I would like some time to gather my wits and concentration before moving forward in earnest. |
|
I was so excited when I read the announcement there was going to be a RFC process, something formal to provide some technical leadership and cohesion. Then, last night I read this whole comment section. It made me angry, and I had to exercise great restraint. My feelings, personally, is that
I wanted to be brief after all of the WOT posts, and feel that I have utterly failed, and I am sorry. I feel stronger than the moji let me express. |
|
I deeply appreciate your kind words and feedback @aphor |
|
Based on comments received, below aspects were discussed internally:
|
|
Ok. |
There are a bunch of RFCs merged already in a directory named Are you going to change the name of this repo along with the directory in the salt repo, and should we start changing the titles of the current open RFCs? This will also require that somebody submit a PR to update the release notes for six previous releases which reference the old phrasing to update them to the new name and also change the four references to RFCs which are currently present in the published documentation. You'll probably also need to update the CONTRIBUTING.md file as well as it is now out-of-date. |
|
Thanks for the reminder @cachedout ! We will cover what that migration all looks like once we make the move. For now new RFCs can be managed in these 2 locations until we get this all fixed up. I will try to get this taken care of next week. |
…aster Incorporated changes from #1 (comment)
|
I've renamed this repo and updated the README to reflect the RFC->SEP name, as well as to call out the future CAB proposal. The final comment period came and went without comments - I think in the future we should probably be explicit that an SEP has entered the final comments phase. Probably a label 🙂 |
|
Thanks @waynew !! |
|
Why was the rfc not updated with the comments before it was merged? They are still called RFCs and not SEPs based on this PR? |
|
@gtmanfred is right, lets get this doc cleaned up :) |
I don't think this is relevant in https://github.com/saltstack/salt-enhancement-proposals#2-discussion |
|
I wanted to make sure that it was captured in the doc somewhere because it's far more visible than discussion here on the merged PR. Can you think of a better place to put it? My thought was that ultimately when we have a CAB I expect that the CAB's roles and responsibilities will be called out in that section, since my assumption is that they will be involved in the discussion/etc. Of course all of that will be spelled out when we start hashing out the details 🙂 I also could have skipped adding callout in the doc, but I felt like my tradeoff was putting the callout in there, or creating a CAB SEP. While I'm not opposed to doing that, I also recognize that it would take a while for me to actually flesh out the ideas, meanwhile it might appear that I intentionally left out any mention of a CAB. But if we all find that irrelevant, I'm happy to remove it 😀 |
The proposed process for handling RFCs can be viewed here.