Change proposals fall in to one of the following categories, each with its own template for new topics. Go to a classification's topic for a form to create a new topic of that classification using the ChangeProposalForm
and the appropriate template, or use WebCreateNewTopic
which contains forms for creating any kind of topic for the forms available in this web.
A ChangeProposal's CurrentState
field is used for tracking its development status. It can take the following states:
The workflow for this field is as follows: #CurrentStateWorkflow
- 07 Dec 2004
Discussion and Feedback
Sam, it might be better to rename
since a feature might be implemented as a Add-on, Contrib or Plugin as we have seen in the recent SpamDefeatingViaNofollowAttribute
- 23 Jan 2005
- 24 Jan 2005
In the diagram
also needs to be renamed (I was not able to do that, since it is protected).
- 26 Aug 2005
Thanks for pointing that out Michael, I've fixed the label and the url in drawing.
- 30 Aug 2005
what has to be done with an invalid or denied change proposal? just delete them? this is not clear from the description above. (I am asking because of http://twiki.org/cgi-bin/view/Codev/AttachmentVersionConfusion
- 07 Sep 2006
now has a BugTracking
field. See EdinburghReleaseMeeting2006x09x04
and it's IRC log for details.
- 02 Oct 2006
I find the word "RejectedProposal" a bit too strong. How about "NotApplicableProposal" or "NotSuitableProposal"?
- 09 May 2007
Back to the "RejectedProposal" question. I'd like to have that renamed to "NotSuitableProposal".
Also, as we can see in GoogleDocs
, there is a need for a state other than RejectedProposal
(which goes to the release meeting for decision.) The GoogleDocs proposal is obviously not something the majority would want implemented as a core feature, it is a candidate to be ImplementedAsExtension
. Hence the need for a "please proceed with an extension". Call that "ProceedAsExtension"? Or, better, rename "ImplementedAsExtension" to "ImplementAsExtension", which can mean "please do" or "aleady done".
- 24 Jan 2008
I think having 2 seperate states - one suggesting that a feature is a needed Extension, and another for things which are already implemented (but some were unaware) would be very useful. The UI discussion for Topic Access permissions springs to mind - WebPermissionsPlugin
already implements a templated topic permission UI, but, 'who knew' :).
- 24 Jan 2008
I found out that the current workflow won't work well for bugs.
- 11 Sep 2008