develooper Front page | perl.perl5.porters | Postings from June 2022

the RFC process is a pain

Thread Next
Ricardo Signes
June 18, 2022 19:13
the RFC process is a pain
Message ID:

I am glad we have tried to formalize "how we decide to change the design of things in perl" to something more structured than "post on p5p until you give up or get it."  The RFC process as it's currently in place <>, though, feels like it's not good enough yet.

Here's the diagram from the process:
                            mail p5p
              better           |         rejected
                on     <-------?------->   with
               CPAN            |         reasoning
                        Exploratory RFC
            "we think this idea is worth exploring"
            (Help us figure out how this will work)
                         Provisional RFC
          "we think this idea is worth implementing"
          (We have a firm idea of what we want to do)
                           Accepted RFC
              "we think this plan looks viable"
           (There is a sane plan for how to do it)
                         Implemented RFC
               "docs, tests and implementation"
            (And we can support it in the future)
In a stable release, subject to "experimental features" process
In a stable release, now subject to normal "deprecation" rules

The problem with this as a state diagram is that it defines the *states* pretty well, but very little about the *transitions*.

First:  what happens at that "?" box after submission to p5p?  Then, if the next result is "exploratory RFC", who decides that?  How is it communicated?  Who is responsible for doing it, whatever "it" is?  (It seems to be "someone who can commit to the RFCs repo assigns an ID and creates the exploratory RFC, which I believe means "edits the README file.")

I would like to rewrite this document, not to change particularly much, but to very clearly define each phase and how the RFC moves from one to the other, and who is intended to do what.  I may propose some procedural changes if documenting current ones makes clear that current procedures are too unclear or onerous.

Finally, I am tempted to include "discussion belongs on p5p, not Yet Another Issue Tracker," unless stopped.  While code review on GitHub is just great, having three places for discussion of designs is not.

This is your chance to get out in front of me and say "don't do it!" or "I will buy you a beer if you get it done by July!"  I am not looking for suggestions on massive overhauls at this time.

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About