I like the @modius’s general outline, however it seems that this is entirely forum-centric? When does an issue in the bug tracker actually get raised?
Here’s my thoughts. The idea phase is dead on, however, once we enter the proposal phase, an issue needs to be generated. I personally think proposals/specs should have their own project in Jira. Oh, and no work should ever be done against a proposal issue.
So lets say a new project, LSPEC, is created. There are three issue types: Proposal, Mini-spec, and Major-spec. Proposal issues can be created by anyone, while *-spec’s can only be created by a yet-to-be defined group of trusted individuals (the TAG I assume?).
A possible workflow for these issues could be:
Proposals are created with a “new” or “pending” status
(Assuming this is possible) Proposals are locked for comments until they enter a “open for discussion” status.
Proposals that do not meet requirements, or in some way are non-starters are rejected and closed by the project manager.
If there are no major objections, the proposal’s status is changed to “open for discussion”.
During the discussion phase, any appropriate edits to the proposal’s text can be made.
Given an appropriate amount of time (say a minimum of 7 days) the issue is put into a “pending approval” status.
It is at this point the TAG votes on the issue.
There could be several possible outcomes, 3 that come to mind are: 1) Closed-Approved, 2) Closed-Rejected, and 3) Amended (requires further discussion)
Once a proposal issue is approved, a mini-spec issue is created based on the proposal’s text, or referencing the proposal issue.
Mini-spec issues are immediately closed.
When it comes time to draft the next major specification, a new major specification issue is drafted, and selected mini-specs are assigned as children.
The major-spec issue is then voted on by the TAG, and once approved, is given a version number.
Back on the LDEV project, Feature issues are raised that reference any mini-spec’s that they support.
Using Jira this way, you now have traceability from proposal all the way through work completed. Also, language specifications are tracked separately from actual language development. You can then mark the server version as conforming to spec X, or partially conforming, etc…
Just wondering if any one has seen PHP’s RFC process? I happened to bump into it and it appears as fairly clear, open, and robust process. I have not had any experience with it myself but I think it is worth a review/read.
That’s really informative. Here’s their page on “How to create an RFC”: PHP: rfc:howto.
I wonder if @dajester2013’s motion of using JIRA to track a proposal could be used to similar effect. i.e. you could have an RFC issue type with a specific workflow. Discussion happens in Lang, formalizing the spec happens in JIRA. A board could be created for RFC visibility.
I’m torn personally - there’s a real clarity in the PHP RFC pages that you might lose in JIRA (with all the UI around it). But the process may be easier to maintain and use in JIRA.
Discourse has a number of features that would allow a semi formal progression along the lines proposed
we can move topics between categories
categories can have specific restrictions such as creation rights for proposals/mini-specs
contributions can be appropriately curated into separate topics and/or integrated into a WIKI post
curation responsibilities can be easily distributed across the community
While its not as formal as a JIRA issue type, the forum would be a lot easier to administer. I think we’re probably feeling our way here a bit. If we end up with 50 pending proposals then a move to more formal workflow might be appropriate, but if we end up with 10 then the forum should be just fine.
By recommending the forum, I was shooting for a manageable and pragmatic first step to start organising the process.
Right, that’s sort of what I was going for… Of course, I have to deal with CMMI 3 processes here at work, so I accept that my suggestion may have been somewhat overkill, but for traceability, Jira is built for that purpose.
As long as you guys have a process defined that works, and that you can document and follow, that’s all that really matters. I like @dom_watson’s flow chart.
FWIW, Rust manages this by having initial discussions on Discourse then creating an RFC as a Markdown document in GitHub and using issues and pull requests to refine the wording etc.
I am not for using discourse beyond the discussion phase. @modius Surely during the course of adding to the language more than 10 proposals will be created. If we were just talking about 10 things then there would be no need for a process.
Without wishing to speak for @modius, I’m pretty sure he meant “at the same time” and I think that keeping the number of proposals under active development to a reasonably small number would help foc… squirrel! Er, sorry, help focus people on the issues at hand.
Upon rereading @modius’s comments you are most likely right but even with 10 pending proposals having a more structured system in place sounds like a better idea. In the past with railo and currently with Lucee we discussed items on google groups but changes are handled via JIRA tickets. If I want to see what is up with an issue I don’t search the groups I look at the tickets.
One thing I think that’s good about the PHP RFC system is the index page in the wiki that is just a list of links to RFC’s grouped by status. Whichever system is used, implementing such a page could provide the clear visibility that’s wanted. This could either be done automatically or manually curated as part of the process.
