Tags:
create new tag
, view all tags

Change Proposals

Classification

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.

Topic Classification Template Description
FeatureRequest FeatureRequestTopicTemplate Request for additional functionality
BugReport BugReportTopicTemplate Report a bug in existing functionality
CodeRefactor CodeRefactorTopicTemplate Proposals to modify the way code is written without changing functionality
DocRequest DocRequestTopicTemplate Requests documentation that will be bundled with releases

Workflow

A ChangeProposal's CurrentState field is used for tracking its development status. It can take the following states:

Name Type Tooltip Message
UnderInvestigation option New proposal which is not yet been fully discussed or decided upon.
ReadyForReleaseMeeting option Discussion has finished and proposal is ready to be voted for at next release meeting
AcceptedProposal option Proposal was accepted and ready to be implemented
RejectedProposal option Proposal was rejected
ClosedProposal option Proposal was closed due to duplicate proposal or retracted proposal
UnderConstruction option For an accepted proposal documentation and coding started. Please give Item number in BugTracking field
MergedToCore option Has been merged to core or default plugin
ImplementedAsExtension option It was implemented as an optional contrib/plugin/addon, and doesn't need a core merge
ParkedProposal option Proposal needs someone to drive it

The workflow for this field is as follows: #CurrentStateWorkflow

UnderInvestigationAcceptedProposalRejectedProposalConsensusReachedSevenDayFeedbackPeriodConcernRaisedByReadyForReleaseMeetingUnderConstructionMergedToCoreParkedProposalImplementedAsExtensionDrawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)

-- SamHasler - 07 Dec 2004


Discussion and Feedback

Sam, it might be better to rename ImplementedAsContrib to ImplementedAsExtension since a feature might be implemented as a Add-on, Contrib or Plugin as we have seen in the recent SpamDefeatingViaNofollowAttribute feature.

-- PeterThoeny - 23 Jan 2005

Done.

-- SamHasler - 24 Jan 2005

In the diagram ImplementedAsContrib also needs to be renamed (I was not able to do that, since it is protected).

-- MichaelSchmidt - 26 Aug 2005

Thanks for pointing that out Michael, I've fixed the label and the url in drawing.

-- SamHasler - 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)

-- MatthiasThullner - 07 Sep 2006

ChangeProposalForm now has a BugTracking field. See EdinburghReleaseMeeting2006x09x04 and it's IRC log for details.

-- SamHasler - 02 Oct 2006

I find the word "RejectedProposal" a bit too strong. How about "NotApplicableProposal" or "NotSuitableProposal"?

-- PeterThoeny - 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".

-- PeterThoeny - 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' :).

-- SvenDowideit - 24 Jan 2008

I found out that the current workflow won't work well for bugs.

-- TWikiJanitor - 11 Sep 2008

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2011-12-06 - GeorgeTrubisky
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.