Question: Does Lucee need a RFC process? And if so what should that process
look like…
Here are some links for reference PHP: rfc:howto and
https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Thanks for those links Steven. Very informative both on the rfc and the process of what go on during the process.
Mark Drew
- Sent by typing with my thumbs.> On 16 Jun 2015, at 14:35, Steven Neiland <@Steven_Neiland> wrote:
Question: Does Lucee need a RFC process? And if so what should that process look like…
Here are some links for reference PHP: rfc:howto and https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/e95ef7c2-2f46-4f6e-89bf-24c46ca20158%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Agreed that a full RFC might be too much to start out with but we really
need something a bit more formal and visible than what we currently have.
Im imagining something along the lines of a cut down RFC which describes a
language/feature change, why it is proposed (what problem it solves) and
how to deal with any breaking changes it might introduce. Put it in a
directory on git and link to it from the lang forum to discuss the merits.
Then once LAS has heard the arguments for against and any modifications the
document could be accepted/rejected with reasons and listed on the website.
That way we A) have a transparent process as to what decisions are being
made and why plus B) a starting specification for changes before they are
developed and something that can be tested against.
+1
Andrew PenhorwoodOn Wednesday, June 17, 2015 at 8:12:20 AM UTC-4, Steven Neiland wrote:
Agreed that a full RFC might be too much to start out with but we really
need something a bit more formal and visible than what we currently
have.Im imagining something along the lines of a cut down RFC which describes a
language/feature change, why it is proposed (what problem it solves) and
how to deal with any breaking changes it might introduce. Put it in a
directory on git and link to it from the lang forum to discuss the merits.
Then once LAS has heard the arguments for against and any modifications the
document could be accepted/rejected with reasons and listed on the website.That way we A) have a transparent process as to what decisions are being
made and why plus B) a starting specification for changes before they
are developed and something that can be tested against.