The OSRA’s Technical Committee on Enhancement Proposal Processes has been working over the past few months to produce a replacement for the current ROS Enhancement Proposal (REP) process, which is now severely out of date and doesn’t work with our current tools (we don’t, for example, have the mailing list it requires anymore). The TC has been looking at what no longer works with the current REP process, as well as what many other organisations with similar processes do.
As part of this work, the TC has run into that most difficult of questions: what is in scope? In other words, when do you need to send in an Enhancement Proposal and follow the prescribed process to get it approved/accepted, and when can you just go ahead and submit a PR?
So far we’ve come up with some obvious ones that we think might be in scope, like making significant changes to an external API. However this is something of a braintstorming exercise, and the more brains doing some storming, the better.
So, now that most of us are moving into a week or two of not-working-that-much, I’d like to hear your thoughts. For what should you need to follow a REP-like process? What should never be in scope? What is in the grey zone and would need discussion on a case-by-case basis?
Thanks for the initiative! I’ll try to summarize my view.
If the proposed change obviously has more interested “parties” (i.e. robotic domains) and the proposer of the change cannot cover all, there should be a REP in which all the relevant parties express their needs and opinions.
On the other hand, if the change is specific for one domain, it does not necessarily need a new REP (if there is a good agreement in the domain).
Things like new common message definitions are kind of borderline for me. Almost no common messages have undergone a rep process, but the message acceptance process was usually quite thorough and it was very similar to a rep (with additional requirements like existing implementations).
What might require a rep is when there is a good reason to change something already working for something that works even better. That would be e.g. the new IMU definition rep.
Also, REPs should be required for all “standards” that aren’t quite easily validated in code. That would be for example the requirement to use SI units wherever possible.
IMO, the following is general open-source motivation and policy why we have enhancement proposal process, but i think it still stands out.
when do you need to send in an Enhancement Proposal and follow the prescribed process to get it approved/accepted
When we are proposing the new features that requires the significant changes to the repositories before implementation.
This can do save our (contributors, developers and maintainers) time and effort before committing and reviewing the implementation, eventually better for community development health.
As developers perspective, checking if the proposed feature including basic design/drivers can be acceptable for the community before implementation is really important to know.
As maintainer’s and TC’s perspective, they can be responsible to answer if the feature is acceptable or not in early stage during reviews and discussions. Or what needs to be fixed and addressed to be acceptable in technical feedbacks. I believe, clear decision at this phase is really important for the community, instead we might lose or waste the huge effort and time for contributors, that i believe really bad development process for the community.