Umbraco now has a RFC process, excellent! However just having one doesn't mean its working. Admittedly its very early days however already I and others have spotted some areas that need some thought/attention/direction and better to head it off sooner rather than later.
I've had chat about all these in private with various people but to me this is something that should be a public discussion.
Some queries that have sprung to mind:
The name says it all
An RFC is traditionally called a "Request for Comment". Not a contribution but comment. Its about encouraging discussion that moves the issue forward or shines light on areas that might have been over looked. So we should encourage comments but for that the RFC need to be written in a way you can actually comment on them. Several on the ones open currently are very long and wordy while often saying little. They read more like legal documents intended to give maximum wiggle room before making a decision rather than helping people get to a consensus of a solution/plan. We need to fix that.
What are RFC's for?
To me they are a place to invite and curate input about a feature/suggestion/change so that a consensus of opinion can be reached and then actioned on or not. The results of that chat are documented though-out in the open in a manner anyone can take part. The balance though is to stop "bike shedding" chats (https://exceptionnotfound.net/bikeshedding-the-daily-software-anti-pattern/) while also giving room for good ideas and input to surface.
If you look at the current crop of RFCs they are all big epic tasks. Trouble is they all seems to be very open, very blue sky thinking, yet oddly nearly all proposing a solution of one sort or another. This gives the impression that only EPICS are suitable for RFC when in fact small tasks could be a RFC too. Recent examples are the discussion on "to revert to Tabs or not to tabs" and adding an additional step to the property editor picker when creating doctypes. Both would make perfect RFC as they both generated input and insight from multiple parties.
Who can raise RFCs?
An RFC should be cheap to spin up and start getting input on. In open source land timing and momentum are key. If you have several devs talking and discussion an issue passionately on twitter then we should get them recording that on a RFC asap before they all move on and nothing gets done. The current restriction (which I'm trying to follow) is we have to create an post here first, then move it to github and only then can we make it a RFC if HQ approve. I think that is simply too many barriers to entry. I understand why its there or why its thought there is a need for it there but its actually hindering input. Closing or rejecting a RFC is relatively cheap so why not just let anyone create one as long as they follow the rules in the template? We will capture more input at the time its occurring like that.
RFC's within Umbraco community came about as there wasn't a good fit place to have the kind of chats that should be happening in them. Posts on Our were not monitored by HQ and often disappeared. Github didn't seem like the right place to be littering up with "I have a dream..." style ideas and discussions. Hence RFC's entering the stage and about time but they need to be freed up if we are to make anything of them, anyone should be free to spin up a RFC.
What happens with a RFC once its deadline passes
We are in danger of the RFC process becoming a grave yard for good intentions. The current RFCs are simply too big and huge, they cover probably a years work each. How are they likely to become actionable items? If these are the only ones that get made then history will show "we tried it but it didn't work". The current ones should be broken down into smaller RFCs that actually can have a planned outcome, that can have work time committed to and can result in a release relatively quickly. Otherwise they will expire and sit around as they are simply too large to be able to do anything with, the pattern will then be set and it will die a death. RFC's exist in other projects for a reason, lets learn from them and use them as intended. Currently there is nothing to state that HQ have to implement anything discussed in an RFC, they might as well be a nice cosy fire side chat as they stand. I understand HQ's reluctance to commit to tying their hands on this but there is no process to see a RFC through or follow it up. Once the dead line passes then it all goes internal again and becomes subject to sprint planning, shifting priorities, etc. There is nothing mentioned about how RFC's might make it officially on the Road Map or similar so that we know they are "good to go" even if not good to go right now.
Who champions a RFC?
Often an idea will need someone within HQ to champion it within internal meetings and discussions. It would be nice to have a champion or advocate for a RFC if possible. The rest of us have day jobs so can't always be there waving the flag, we need people inside HQ to be pushing the case for these RFCs and getting them on the road map. The best way to do that is have them more focused and smaller I think and having more product owners within HQ itself.
Are HQ allowing time for RFC responses
For the process to work we need input from HQ. Blue sky thinking is all very well but if their aren't the hours to comment on the thoughts or to deliver on the dreams then it is for nothing. RFC should result in an outcome that ideally is actionable (even if that action is "we've all agreed that this isn't going to happen so we are closing this one"). For that though HQ staff need to be eye balling the RFCs and commenting on them. I've waited 13 days now to a follow up to my last comment in a RFC that only has 2 days left to run for instance (https://github.com/umbraco/rfcs/pull/8#issuecomment-499013116). Does this mean HQ should be sat there all day waiting for RFC comments to come in? No, of course not. But some time set aside to answer or comment on them would be valuable so they can do so without squeezing it in and giving it some considered thought. Currently I worry that this time is minimal but it should be allowed for. By doing so we all end up with the same goal...a better CMS.
I've had 4 members of HQ comment privately now that they don't expect to get this RFC process right first time and I might be shot down for raising these issues "to soon". But I didn't learn to drive by crashing into things until I got it right, if we can make corrections when we see they are needed lets do so...that's agile in action!
So, step one of the RFC process is complete, I've created this issue on Our. Next I guess I need a github issue...
I think you like writing as much as I do ;) but i will try to keep my reply as succinct as I can but there's a lot of information here so ...
For me is easiest to split and reply in comments. From what I can tell though, many of your comments and questions are based speculation (maybe by chatting to various people along the way) and possibly not based on what has been defined in the RFC process.
An RFC is traditionally called a "Request for Comment". Not a contribution but comment.
I'm unsure if you are against this naming convention (?) but there are reasons it was called "Request for Contribution" and not "Comment". Part of the RFC description says "As the name suggests, this is an invitation to contribute to the conversation with suggestions and ideas. Please read and respect the RFC Code of Conduct" and this is because we want to encourage contributing constructive ideas and discourage 'commenting' which are not constructive. Part of that is listed in the RFC code of conduct. Like you said: "Its about encouraging discussion that moves the issue forward or shines light on areas that might have been over looked", i feel that constructive discussion is contribution and not simply commenting.
If you look at the current crop of RFCs they are all big epic tasks. Trouble is they all seems to be very open, very blue sky thinking, yet oddly nearly all proposing a solution of one sort or another.
Perhaps identifying the ones you don't feel meet the RFC criteria may help. I don't disagree that some are large tasks but I don't believe that all current RFCs are as you've stated. I'm unsure why you think that it's odd that RFCs are proposing a solution since that is the purpose of an RFC which is to have a documented proposal for a solution. This is the main part of the RFC template.
This gives the impression that only EPICS are suitable for RFC when in fact small tasks could be a RFC too
There's nothing specifically stated in the RFC description about the size of a task required to fulfil an RFC. Though for most small tasks it would probably make more sense to submit a PR, or create an issue on the tracker. As for your examples, I don't think anyone has said these couldn't be RFCs, however to submit an RFCs the full proposal needs to be filled out (more on that below)
The current restriction (which I'm trying to follow) is we have to create an post here first, then move it to github and only then can we make it a RFC if HQ approve
I don't know where you got this idea from as this isn't listed in the RFC description. What it does state is this: "Most changes, including small features, bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Questions or discussions on more substantial changes should first be done on https://our.umbraco.com until further defined to the RFC format if one is deemed necessary." And sure that info can probably be more specific but the gist is that to submit an RFC, the person submitting the RFC will need to complete the RFC template with all relevant information and proposals and not just submit an RFC with empty details to be filled in at a later date. Those details should be defined before the RFC is submitted.
Closing or rejecting a RFC is relatively cheap so why not just let anyone create one as long as they follow the rules in the template
There isn't anything preventing people from submitting one that i know of ?
The current ones should be broken down into smaller RFCs that actually can have a planned outcome, that can have work time committed to and can result in a release relatively quickly.
I believe that is the intention with many of them. RFC 0002: Project IniCore Intro is specifically an RFC that will define several child RFCs and it states this. RFC 0005, RFC 0011, RFC 0012 are all examples of related RFCs that have been broken down.
What happens with a RFC once its deadline passes
There's a lot of questions in this paragraph, I would love to have been provided some suggestions too ;) There is a section in the RFC description called The RFC life-cycle. And yes it does say "When an RFC is accepted, then the process of implementing it may begin in the code repository. Being accepted does not imply anything about the priority of having it implemented and doesn't necessarily indicate that it's in active development." but that doesn't mean that nothing will ever happen. If proposals about ideas and implementations are only written down when they are also being scheduled and approved to start development then I think the outcome is worse than writing/proposing when the ideas are there.
If an RFC does become 'dead' and stale, I don't think there's anything wrong with that, it might just mean that priorities have shifted or other ideas have come along and in which case hopefully other RFCs will take their place. Having a place to describe/document ideas and proposals can only be a good thing whether or not they become reality now, later or never IMO.
Who champions a RFC? - It would be nice to have a champion or advocate for a RFC if possible
It seems that this info is mostly missing from the RFC description. We should make this more clear on the RFC description that the author of the RFC is responsible for maintaining the RFC which means that if it needs to be updated, the author must be willing to make these changes. Because the author owns the PR, the only other way that someone can update the RFC is for the author to grant contribution access to the PR to someone else - which would be totally OK, it would be fine that the author of an RFC is more than one person. The only thing the description currently states in the Instructions section is "Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response."
You'll also notice that at the bottom of every RFC is the "Contributors" section and in my opinion the RFC description should mention that all people listed in this section should be responsible for monitoring, contributing and updating the RFC.
As for someone at HQ - if an HQ person(s) is on the Contributors list, then that is your champion, otherwise potentially one or two folks from HQ could advocate for it. This is a topic that should be better defined.
RFC should result in an outcome that ideally is actionable (even if that action is "we've all agreed that this isn't going to happen so we are closing this one").
Yes i agree, i think that is the intention of an RFC and they will need to be updated by the author accordingly.
For that though HQ staff need to be eye balling the RFCs and commenting on them.
I think this is generally the case, though sometimes it might not be immediate.
I've waited 13 days now to a follow up to my last comment in a RFC that only has 2 days left to run for instance
I'm not sure where you have received a date from? There is no closing date associated with this RFC. The RFC life-cycle explains how an RFC timeframe works and for the one you've mentioned, it hasn't reached a point where the RFC has been tagged and given a final comment period. Unless I've missed something?
The RFC process is certainly not set in stone and it wasn't just made up. The RFC definition credits list a few RFC processes that inspired the Umbraco RFC process. There was a lot of reading/research done in creating this process and trying to simplify it so that it was a little more friendly and that you didn't need to be a lawyer to understand it. Conveniently, the RFC process is a file in a GH repo which means to modify the process itself can be as simple as submitting a PR to the readme and I think any constructive improvements to the RFC process would be wonderful. Like you mentioned "don't expect to get this RFC process right first time" which i think is correct, and i don't think it will ever be Perfect either but it can definitely be continuously improved.
Thanks for getting back so quick and for waiting for my reply.
In short you've cleared up a few of my queries there.
To summarise:
Anyone can create a RFC as long as they fill in all the required fields in the template (https://github.com/umbraco/rfcs/blob/master/0000-rfc-template.md#detailed-design) and follow the instructions (https://github.com/umbraco/rfcs/blob/master/RFC_CREATION.md)
RFCs are for open discussions but for suggesting a solution and then encouraging discussions about that solution.
Ideally you should get a HQ member to "champion" your RFC (although not sure how to go about arranging that). But ultimately the creator of the RFC will be the champion (and any other authors).
Things I'm still hazy on:
Discus first on Our. We should have big open discussions on Our first before a solution is reach (if solution is the right word, its not but its close enough). The trouble is we've had many of these on Our already. The trouble was they always needed HQ to respond to help shape the discussion. Theres not much visibility on "big ideas" posts on Our. This page for instance only had comments from me and you and after the initial retweets is lost in the day to day of Our post history. This in my mind is one of the main reasons that RFCs were needed/requested. A legitimate place to have discussion in public that HQ would have to monitor and common on. This requirement (again maybe too stong a word) might be just a sense checking part to ensure that anything suggest has at least had some discussion somewhere to prevent "daft" ideas which I'd be fine with but the clarity is important other wise "this is something better to discus in a our post" could easily become the defacto knock back to a RFC unless we clear it up.
Who sets the deadline for when comments on a RFC close? There doesn't seem to be anything that I can find on this.
When do RFCs expire? I thought I had seen a date of June 20th for the expiry of the back office RFC but now can't find any evidence of it annoyingly. Possibly my mistake, maybe it was on another RFC. But its been 5 weeks now and still no comment from HQ on that RFC. When is a reasonable about of time to allow for a RFC to become dormant/stall or to be allowed to poke someone for an update? I'd have said 2 weeks should be plenty of time and help keep the conversation going. Without keeping up the momentum of conversation and ideas on these RFCs its easy for them to slip off the radar and rot. Then we have had a lot of discussion and brain power wasted and the RFCs are no better than the Our forum posts they were meant to replace.
Visibility. Probably the biggest issue. As discussed above Our posts get lost too easily. RFC posts could easily go the same way unless more is done. HQ and HQ members should be tweeting, emailing, slacking and posting about the RFC's they are championing to get more eyes on it. Links to the RFC page need to be more prominent on the github page for the project itself, maybe in the github issue template and on the Umbraco website. It should be included in HQ emails and anything else we can do. Shaping the future of Umbraco via an RFC is an important honor and we need more eyes on it to get the best ideas. When a RFC deadline is coming up (10 working days maybe) then HQ should be tweeting that out and getting some last minute input. Or the process is just paper work for paper works sake.
The readme docs you link to have all been changed recently and some of the links are broken it seems but the gist is there. Was going to fix them but I can't find where they are meant to link to.
Once again I think the fact we have a RFC process is great and I know that care was taken by many at retreat to pick it. The issues I'm raising I like to think are about us following through on the RFC process and not just the paper work of it.
A lot of my points above come not just from me but the many people I speak to directly both in HQ and the community. A lot of the "good" I do in Umbracoland is behind closed doors in face-to-face chats at Code Garden and other festivals, on the phone and in DMs. I don't like to name names of those that do talk to me and share their views. But many of the "I don't know where you heard that" style replies above are to queries or assumptions or (mis)understandings coming from HQ or retreat members themselves about this process not just me going off on one. There is confusion, the aim of this post is to clear that up.
I know HQ have meant to be looking into the RFC process this month. When might we have an update on the outcome of that if any?
I liked the organisation of this, very easy to see what's going on, in the proposals, and related discussion issues, but also the idea of regular meetings to discuss progress/ideas intrigued me? maybe this is something that could be considered (quarterly?).
I agree with Pete visibility is an issue, doesn't really seem like anything is going on and it is hard to tell when it is.
As you will have noticed the RFC docs and process has been updated since it was first established and i would imagine that it will be further refined the more we work with it. Most of the points raised here have been discussed and hopefully answered in the updated docs. Some of this process has also been refined just based on working with some of the existing RFCs. Probably a lot of the links mentioned above don't exist anymore but the whole RFC docs/process has been simplified so would encourage you to read the README again and click through the links RFCPROCESS, RFCCREATION
The first bullet point in the RFC readme is the main driver for the Umbraco RFC process
Facilitate the transparency of decision making by Umbraco HQ to Umbraco end-users.
This also means that an RFC in this process will need to be created or championed by an HQ member. I understand the comments/concerns about community led discussions on Our and visibility of chats on there but in my own opinion I think that can be solved by updating Our itself one way or another. A discussion on GH compared to Our is not much different, it's just a linear chat and comments certainly also get lost on GH.
Here's some answers about deadlines and expiry: The RFC_PROCESS page has been updated to reflect this, a deadline is set when the Author is ready to close the RFC. When a deadline is set a tag is added and a date will be applied. We just did this today, see https://github.com/umbraco/rfcs/pull/11. There's no reason why an RFC can't just be open for some time. Ideally though, there's not a whole bunch of open RFCs at one time as is sort of the case now. Each RFC takes some amount of effort to maintain so a deadline will be set when it's ready.
There are active RFCs, i have been working on a couple over the past month. I plan to close #11 next week and have #12 fully updated by next week and then we'll try to apply a final comments period to that one too. I plan on also adding final comment periods to the current .net core ones soon too. So there is stuff being done there.
There is probably a lot of concepts of what "Visibility" means with these RFCs. Whether that's just getting people to subscribe to these GH feeds, tweeting about updates, putting links in various places, explore adding various tags to these GH items on what is 'active' or pending, etc... I can only assume this will get better the more the process is used and evolves.
Refining the RFC process
Umbraco now has a RFC process, excellent! However just having one doesn't mean its working. Admittedly its very early days however already I and others have spotted some areas that need some thought/attention/direction and better to head it off sooner rather than later.
See all active RFCs here: https://github.com/umbraco/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc
I've had chat about all these in private with various people but to me this is something that should be a public discussion.
Some queries that have sprung to mind:
The name says it all
An RFC is traditionally called a "Request for Comment". Not a contribution but comment. Its about encouraging discussion that moves the issue forward or shines light on areas that might have been over looked. So we should encourage comments but for that the RFC need to be written in a way you can actually comment on them. Several on the ones open currently are very long and wordy while often saying little. They read more like legal documents intended to give maximum wiggle room before making a decision rather than helping people get to a consensus of a solution/plan. We need to fix that.
What are RFC's for?
To me they are a place to invite and curate input about a feature/suggestion/change so that a consensus of opinion can be reached and then actioned on or not. The results of that chat are documented though-out in the open in a manner anyone can take part. The balance though is to stop "bike shedding" chats (https://exceptionnotfound.net/bikeshedding-the-daily-software-anti-pattern/) while also giving room for good ideas and input to surface.
If you look at the current crop of RFCs they are all big epic tasks. Trouble is they all seems to be very open, very blue sky thinking, yet oddly nearly all proposing a solution of one sort or another. This gives the impression that only EPICS are suitable for RFC when in fact small tasks could be a RFC too. Recent examples are the discussion on "to revert to Tabs or not to tabs" and adding an additional step to the property editor picker when creating doctypes. Both would make perfect RFC as they both generated input and insight from multiple parties.
Who can raise RFCs?
An RFC should be cheap to spin up and start getting input on. In open source land timing and momentum are key. If you have several devs talking and discussion an issue passionately on twitter then we should get them recording that on a RFC asap before they all move on and nothing gets done. The current restriction (which I'm trying to follow) is we have to create an post here first, then move it to github and only then can we make it a RFC if HQ approve. I think that is simply too many barriers to entry. I understand why its there or why its thought there is a need for it there but its actually hindering input. Closing or rejecting a RFC is relatively cheap so why not just let anyone create one as long as they follow the rules in the template? We will capture more input at the time its occurring like that.
RFC's within Umbraco community came about as there wasn't a good fit place to have the kind of chats that should be happening in them. Posts on Our were not monitored by HQ and often disappeared. Github didn't seem like the right place to be littering up with "I have a dream..." style ideas and discussions. Hence RFC's entering the stage and about time but they need to be freed up if we are to make anything of them, anyone should be free to spin up a RFC.
What happens with a RFC once its deadline passes
We are in danger of the RFC process becoming a grave yard for good intentions. The current RFCs are simply too big and huge, they cover probably a years work each. How are they likely to become actionable items? If these are the only ones that get made then history will show "we tried it but it didn't work". The current ones should be broken down into smaller RFCs that actually can have a planned outcome, that can have work time committed to and can result in a release relatively quickly. Otherwise they will expire and sit around as they are simply too large to be able to do anything with, the pattern will then be set and it will die a death. RFC's exist in other projects for a reason, lets learn from them and use them as intended. Currently there is nothing to state that HQ have to implement anything discussed in an RFC, they might as well be a nice cosy fire side chat as they stand. I understand HQ's reluctance to commit to tying their hands on this but there is no process to see a RFC through or follow it up. Once the dead line passes then it all goes internal again and becomes subject to sprint planning, shifting priorities, etc. There is nothing mentioned about how RFC's might make it officially on the Road Map or similar so that we know they are "good to go" even if not good to go right now.
Who champions a RFC?
Often an idea will need someone within HQ to champion it within internal meetings and discussions. It would be nice to have a champion or advocate for a RFC if possible. The rest of us have day jobs so can't always be there waving the flag, we need people inside HQ to be pushing the case for these RFCs and getting them on the road map. The best way to do that is have them more focused and smaller I think and having more product owners within HQ itself.
Are HQ allowing time for RFC responses
For the process to work we need input from HQ. Blue sky thinking is all very well but if their aren't the hours to comment on the thoughts or to deliver on the dreams then it is for nothing. RFC should result in an outcome that ideally is actionable (even if that action is "we've all agreed that this isn't going to happen so we are closing this one"). For that though HQ staff need to be eye balling the RFCs and commenting on them. I've waited 13 days now to a follow up to my last comment in a RFC that only has 2 days left to run for instance (https://github.com/umbraco/rfcs/pull/8#issuecomment-499013116). Does this mean HQ should be sat there all day waiting for RFC comments to come in? No, of course not. But some time set aside to answer or comment on them would be valuable so they can do so without squeezing it in and giving it some considered thought. Currently I worry that this time is minimal but it should be allowed for. By doing so we all end up with the same goal...a better CMS.
I've had 4 members of HQ comment privately now that they don't expect to get this RFC process right first time and I might be shot down for raising these issues "to soon". But I didn't learn to drive by crashing into things until I got it right, if we can make corrections when we see they are needed lets do so...that's agile in action!
So, step one of the RFC process is complete, I've created this issue on Our. Next I guess I need a github issue...
Hi Pete,
I think you like writing as much as I do ;) but i will try to keep my reply as succinct as I can but there's a lot of information here so ...
For me is easiest to split and reply in comments. From what I can tell though, many of your comments and questions are based speculation (maybe by chatting to various people along the way) and possibly not based on what has been defined in the RFC process.
I'm unsure if you are against this naming convention (?) but there are reasons it was called "Request for Contribution" and not "Comment". Part of the RFC description says "As the name suggests, this is an invitation to contribute to the conversation with suggestions and ideas. Please read and respect the RFC Code of Conduct" and this is because we want to encourage contributing constructive ideas and discourage 'commenting' which are not constructive. Part of that is listed in the RFC code of conduct. Like you said: "Its about encouraging discussion that moves the issue forward or shines light on areas that might have been over looked", i feel that constructive discussion is contribution and not simply commenting.
Perhaps identifying the ones you don't feel meet the RFC criteria may help. I don't disagree that some are large tasks but I don't believe that all current RFCs are as you've stated. I'm unsure why you think that it's odd that RFCs are proposing a solution since that is the purpose of an RFC which is to have a documented proposal for a solution. This is the main part of the RFC template.
There's nothing specifically stated in the RFC description about the size of a task required to fulfil an RFC. Though for most small tasks it would probably make more sense to submit a PR, or create an issue on the tracker. As for your examples, I don't think anyone has said these couldn't be RFCs, however to submit an RFCs the full proposal needs to be filled out (more on that below)
I don't know where you got this idea from as this isn't listed in the RFC description. What it does state is this: "Most changes, including small features, bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow. Questions or discussions on more substantial changes should first be done on https://our.umbraco.com until further defined to the RFC format if one is deemed necessary." And sure that info can probably be more specific but the gist is that to submit an RFC, the person submitting the RFC will need to complete the RFC template with all relevant information and proposals and not just submit an RFC with empty details to be filled in at a later date. Those details should be defined before the RFC is submitted.
There isn't anything preventing people from submitting one that i know of ?
I believe that is the intention with many of them. RFC 0002: Project IniCore Intro is specifically an RFC that will define several child RFCs and it states this. RFC 0005, RFC 0011, RFC 0012 are all examples of related RFCs that have been broken down.
There's a lot of questions in this paragraph, I would love to have been provided some suggestions too ;) There is a section in the RFC description called The RFC life-cycle. And yes it does say "When an RFC is accepted, then the process of implementing it may begin in the code repository. Being accepted does not imply anything about the priority of having it implemented and doesn't necessarily indicate that it's in active development." but that doesn't mean that nothing will ever happen. If proposals about ideas and implementations are only written down when they are also being scheduled and approved to start development then I think the outcome is worse than writing/proposing when the ideas are there.
If an RFC does become 'dead' and stale, I don't think there's anything wrong with that, it might just mean that priorities have shifted or other ideas have come along and in which case hopefully other RFCs will take their place. Having a place to describe/document ideas and proposals can only be a good thing whether or not they become reality now, later or never IMO.
It seems that this info is mostly missing from the RFC description. We should make this more clear on the RFC description that the author of the RFC is responsible for maintaining the RFC which means that if it needs to be updated, the author must be willing to make these changes. Because the author owns the PR, the only other way that someone can update the RFC is for the author to grant contribution access to the PR to someone else - which would be totally OK, it would be fine that the author of an RFC is more than one person. The only thing the description currently states in the Instructions section is "Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response."
You'll also notice that at the bottom of every RFC is the "Contributors" section and in my opinion the RFC description should mention that all people listed in this section should be responsible for monitoring, contributing and updating the RFC.
As for someone at HQ - if an HQ person(s) is on the Contributors list, then that is your champion, otherwise potentially one or two folks from HQ could advocate for it. This is a topic that should be better defined.
Yes i agree, i think that is the intention of an RFC and they will need to be updated by the author accordingly.
I think this is generally the case, though sometimes it might not be immediate.
I'm not sure where you have received a date from? There is no closing date associated with this RFC. The RFC life-cycle explains how an RFC timeframe works and for the one you've mentioned, it hasn't reached a point where the RFC has been tagged and given a final comment period. Unless I've missed something?
The RFC process is certainly not set in stone and it wasn't just made up. The RFC definition credits list a few RFC processes that inspired the Umbraco RFC process. There was a lot of reading/research done in creating this process and trying to simplify it so that it was a little more friendly and that you didn't need to be a lawyer to understand it. Conveniently, the RFC process is a file in a GH repo which means to modify the process itself can be as simple as submitting a PR to the readme and I think any constructive improvements to the RFC process would be wonderful. Like you mentioned "don't expect to get this RFC process right first time" which i think is correct, and i don't think it will ever be Perfect either but it can definitely be continuously improved.
Hi Shannon,
Thanks for getting back so quick and for waiting for my reply.
In short you've cleared up a few of my queries there.
To summarise:
Things I'm still hazy on:
The readme docs you link to have all been changed recently and some of the links are broken it seems but the gist is there. Was going to fix them but I can't find where they are meant to link to.
Once again I think the fact we have a RFC process is great and I know that care was taken by many at retreat to pick it. The issues I'm raising I like to think are about us following through on the RFC process and not just the paper work of it.
A lot of my points above come not just from me but the many people I speak to directly both in HQ and the community. A lot of the "good" I do in Umbracoland is behind closed doors in face-to-face chats at Code Garden and other festivals, on the phone and in DMs. I don't like to name names of those that do talk to me and share their views. But many of the "I don't know where you heard that" style replies above are to queries or assumptions or (mis)understandings coming from HQ or retreat members themselves about this process not just me going off on one. There is confusion, the aim of this post is to clear that up.
I know HQ have meant to be looking into the RFC process this month. When might we have an update on the outcome of that if any?
I stumbled on the c# language design repo the other day
https://github.com/dotnet/csharplang
I liked the organisation of this, very easy to see what's going on, in the proposals, and related discussion issues, but also the idea of regular meetings to discuss progress/ideas intrigued me? maybe this is something that could be considered (quarterly?).
I agree with Pete visibility is an issue, doesn't really seem like anything is going on and it is hard to tell when it is.
Hi Kevin,
that's also what I suggested one day as well with a combination of "community meetings" which may result with some cool notes and inputs as well.
Hi all,
As you will have noticed the RFC docs and process has been updated since it was first established and i would imagine that it will be further refined the more we work with it. Most of the points raised here have been discussed and hopefully answered in the updated docs. Some of this process has also been refined just based on working with some of the existing RFCs. Probably a lot of the links mentioned above don't exist anymore but the whole RFC docs/process has been simplified so would encourage you to read the README again and click through the links RFCPROCESS, RFCCREATION
The first bullet point in the RFC readme is the main driver for the Umbraco RFC process
This also means that an RFC in this process will need to be created or championed by an HQ member. I understand the comments/concerns about community led discussions on Our and visibility of chats on there but in my own opinion I think that can be solved by updating Our itself one way or another. A discussion on GH compared to Our is not much different, it's just a linear chat and comments certainly also get lost on GH.
Here's some answers about deadlines and expiry: The RFC_PROCESS page has been updated to reflect this, a deadline is set when the Author is ready to close the RFC. When a deadline is set a tag is added and a date will be applied. We just did this today, see https://github.com/umbraco/rfcs/pull/11. There's no reason why an RFC can't just be open for some time. Ideally though, there's not a whole bunch of open RFCs at one time as is sort of the case now. Each RFC takes some amount of effort to maintain so a deadline will be set when it's ready.
There are active RFCs, i have been working on a couple over the past month. I plan to close #11 next week and have #12 fully updated by next week and then we'll try to apply a final comments period to that one too. I plan on also adding final comment periods to the current .net core ones soon too. So there is stuff being done there.
There is probably a lot of concepts of what "Visibility" means with these RFCs. Whether that's just getting people to subscribe to these GH feeds, tweeting about updates, putting links in various places, explore adding various tags to these GH items on what is 'active' or pending, etc... I can only assume this will get better the more the process is used and evolves.
is working on a reply...