This seems to be a worthwhile exercise to explore -- formal but lightweight, and a lodestone during development.
That said, a ticketing system should ostensibly offer this same effect, but in my experience they're often populated with brief titles and maybe a short paragraph on expectations.
romannikolaev 2 days ago [-]
We usually use this before tickets are even created.
In many cases, an RFC can lead to an epic-level ticket that includes multiple user stories.
In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.
pstuart 2 days ago [-]
A benefit of the RFC approach is if it lives in the repo itself the documentation is along side the code.
Anything that will prompt stakeholders to engage and clarify expectations is a win. It's hard to make this happen even when everybody is philosophically aligned on the need to do so, so reframing it as an RFC could be quite the useful "One Weird Trick" ;-).
observationist 2 days ago [-]
Ticketing systems inevitably get Goodharted. Everyone starts in good faith, then the manager starts using the number of tickets closed, touched, etc as a proxy for work being done, then the agents replace number of tickets with things actually accomplished.
Rendered at 05:29:37 GMT+0000 (Coordinated Universal Time) with Vercel.
That said, a ticketing system should ostensibly offer this same effect, but in my experience they're often populated with brief titles and maybe a short paragraph on expectations.
In other cases, it can be very tactical. I think you are right, probably it can be expressed directly in the form of a ticket. The discussion well happen in the comments to the ticket in this case.
Anything that will prompt stakeholders to engage and clarify expectations is a win. It's hard to make this happen even when everybody is philosophically aligned on the need to do so, so reframing it as an RFC could be quite the useful "One Weird Trick" ;-).