Changes between Version 3 and Version 7 of Ticket #1127


Ignore:
Timestamp:
05/17/11 09:00:50 (3 years ago)
Author:
sebbacon
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1127

    • Property Status changed from new to closed
    • Property Resolution changed from to fixed

  • Ticket #1127 – Description

    v3 v7  
    55== Abstract == 
    66 
    7 When adding new features to CKAN, a longer, more formal discussion will improve software design quality and documentation, better engage 
     7When adding major new features to CKAN, a longer, more formal discussion  
     8will improve software design quality and documentation, better engage 
    89the wider community, and ensure the core team are up to date with 
    910latest developments.   
    … …  
    1617very informal, typically based around one person's great idea, which 
    1718they've discussed with one or two other people in the team.  The 
    18 originator of the idea is typically the only person with access to all the input they've had through such discussions.  Often, the only location of this information is  in that person's head. 
     19originator of the idea is typically the only person with access to  
     20all the input they've had through such discussions.  Often, the only  
     21location of this information is  in that person's head. 
    1922 
    2023However, there is a lot of experience embodied in the CKAN community 
    … …  
    3841likely to involve matters of opinion in its design. 
    3942 
    40 If a feature requires a CREP, the proposer must first find a seconder 
     43A developer may decide that a CREP is too formal and long-winded. The  
     44decision to write a CREP is at at their discretion; however, new  
     45features MUST always be proposed via email, even if this is just a  
     46couple of sentences. 
     47 
     48If a feature requires a CREP, the proposer should find a seconder 
    4149for their idea.  This sanity check step happens before a CREP is 
    4250written to ensure at least the possibility of consensus on the CREP. 
    4351 
    4452Next the proposer should write a CREP, starting by copying and pasting 
    45 the [http://wiki.ckan.net/CKAN_Revision_and_Enhancement_Proposals template on the wiki] into a new Trac ticket.  This will be with a 
    46 CREP status of "draft" and Type of "CREP..  The proposer should notify 
     53the [http://wiki.ckan.net/CKAN_Revision_and_Enhancement_Proposals template on the wiki] into a new Trac ticket.  This will be with a status of "new" and Type of "CREP".  The proposer should notify 
    4754the [http://lists.okfn.org/mailman/listinfo/ckan-dev ckan-dev] mailing 
    4855list, and possibly the 
    … …  
    5461CREP updated to reflect the current consensus. 
    5562 
    56 Once consensus has been reached, the ticket should be marked as 
     63Once consensus has been reached, the ticket should be marked with the 
    5764"accepted" status and assigned to a CKAN release milestone. 
    5865 
    59 When an accepted CREP has been implemented, it should be marked as 
    60 "completed". 
     66When an accepted CREP has been implemented, it should be resolved as 
     67"fixed". 
    6168 
    6269If no consensus can be reached on a draft CREP, or for some reason an 
    63 accepted CREP doesn't get completed, it should be marked as 
    64 "rejected". 
     70accepted CREP doesn't get completed, it should be marked as or "wontfix". 
    6571 
    66 If a completed CREP becomes obselete, it should be marked as "obselete". 
     72If a completed CREP becomes obsolete, it should be marked as "invalid",  
     73with a note pointing to the obsoleting ticket(s) 
    6774 
    6875== Why do it this way ==  
    … …  
    95102timescales. 
    96103 
     104All this policy about structure should not be construed as mandatory.   
     105In particular, the later fields in the CREP template regarding  
     106Implementation Plan may be omitted if the author doesn't find them  
     107helpful. 
     108 
    97109Some projects (e.g. Debian) keep their enhancement proposals in a 
    98110versioning repository; others (e.g. Plone) keep them in an issue 
    … …  
    106118== Backwards Compatibility == 
    107119 
    108 Some [https://bitbucket.org/okfn/ceps/src/76b274888bcf/cep/ legacy enhancement proposals], called CEPs, have previously been started. 
     120Some [https://bitbucket.org/okfn/ceps/src/76b274888bcf/cep/ legacy  
     121enhancement proposals], called CEPs, have previously been started. 
    109122 
    110123They are currently all marked as "active".  Any which require 
    … …  
    133146=== Participants === 
    134147 
    135 Once agreed, we need a CREP champion -- as yet unassigned 
     148Seb Bacon: as current Documentation Czar (May 2011), responsible for  
     149ensuring CREPs are up to date. 
    136150 
    137151=== Progress ===