Delete docs about RFC process - or start following the process again

[GuySartorelli]

There are some docs about an RFC process that we haven't followed for a long time - especially the "what next" section which talks about a monthly catchup that just doesn't happen.

We should either delete these misleading docs, or start following an RFC process again.

[GuySartorelli]

@silverstripe/core-team thoughts?

[madmatt]

We should delete docs that aren't correct / relevant, definitely agree with that.

I think the question here is "Should there be an RFC process that is followed?" As I recall, this process was more meant to be 'for people outside of the core team who want to propose a new feature or significant change, use the RFC process' - but I could be wrong about that.

As far as I know, the RFC process was only really used by the core team and others at Silverstripe Ltd (the old 'CMS Squad'), so it never really took off as a process.

Putting barriers up to contribution isn't ideal, but neither is someone doing a big change that ultimately gets rejected because it doesn't align with some theoretical/unspoken future vision.

Not sure what the right answer is, but if we don't want to continue with RFCs then I'm fine with deleting the docs.

[GuySartorelli]

I think the question here is "Should there be an RFC process that is followed?"

Yes, sorry, I should have made that clearer.

Putting barriers up to contribution isn't ideal, but neither is someone doing a big change that ultimately gets rejected because it doesn't align with some theoretical/unspoken future vision.

Agreed on both fronts.
I think it's telling that none of our contributing docs point people to making RFCs - the issues and bugs page tells people to discuss features in "the "feature ideas" forum category and our community channels" - if we were encouraging the RFC process, that's where I would put a link to the RFC page.

I personally think the RFC process is a good idea, but that we're not currently in a state where we can properly encourage its use. IMO we should delete that page, and instead make it really really clear how people can discuss features they want to implement (be it on the forums, or in an issue (but only if they truly intend to do the implementation work themselves preferably) or maybe we even start using the GitHub discussions feature).

There's an issue (unfortunately it was created in the product issues repo for some reason so you won't have access to it) to review our contribution documentation and make sure it's up to date so we can probably handle the "what do we do instead of RFCs" part separately from this issue, and instead here just focus on "do we want to use an RFC process at all?"

[michalkleiner]

No conclusive answer from me here, but I think there should be a process where core committers (and other highly active community members/contributors) outside of the SS Ltd employees have their say on the direction of things. So I probably wouldn't point blank delete all the current docs unless we know what we want to be doing. I guess I'm leaning towards return to the process in some way for transparency on decisions and for the community to not think that all calls are made within SS Ltd.

[emteknetnz]

¯\(ツ)/¯ I never felt the RFC process really added a whole lot, at least not in my time in the CMS squad. Someone would propose something, it would get some discussion and maybe a handful of votes. But we can do the "propose a thing on github and have a discussion" thing easily enough minus a formal process + voting.

Contribution ultimately just comes down to an individual having good ideas that people agree with and the motivation to follow through on those ideas with high quality pull-requests. An RFC process doesn't really change that. I feel like a formal voting process is really more suitable for far larger open source projects than this one.

[lozcalver]

I’d be keen to start using GitHub discussions instead, people can post ideas in as little or as much detail as they like without polluting issues. The forums aren’t ideal for this kind of thing and Slack has limited history, so it seems like the best fit to me.