[wp-hackers] Improving WordPress Core Development

[Dion Hulse (dd32)]

On Tue, 29 Dec 2009 07:31:46 +1100, Dan Cole <wp at dan-cole.com> wrote:
> <snip>

Sounds good to me, Here's my long brainstorm of some changes which could  
be useful.
Please note, That when i say a clear policy, I mainly mean a published  
document somewhere redibly accessable by users that explains it all. I  
also do not intend to attack anyone personally, if something i mention  
sounds like something you may have done, Do not take it as an arguement,  
Its mainly my opinion of how i'd like to see things happen.

I'd like to preface it by saying that WordPress in general seems to be  
staying pretty open about whats happening, although i agree that sometimes  
theres a bit of a "so and so said this was coming in 3.0!" etc sort of  
item before theres even been a meeting to decide.. but sometimse  
developers will get behind something and do it, knowing its in the end  
users best interests, you have to trust them sometimes :) - Make sure you  
read the Setting Scope blog post however before anyone comments on that  
statement please.


I see a few things that WordPress needs:
  * A clear policy on what types of patches goes into what release,  
specifically, point releases -  
http://westi.wordpress.com/2009/12/19/what-should-go-into-a-wordpress-maintenance-release/
  * A clear policy on when the last enhancement ticket gets commited  
(Feature Frozen)
    * Would prefer that hook-aditions are exempt from this, As its when  
plugin developers are testing they realise where an extra hook would be  
good - Hook additions only (no new refactoring or lots of code changing  
for it to happen)
  * A clear policy on beta/RC timeframes, Ie. Once feature frozen, 2 weeks  
later, beta1.
   * This is not as easy, as it highly depends on what functions are being  
worked on. So no hard limit, just a general published example of "2-3  
weeks between feature frozen and beta1, approximately 1-2 weeks between  
subsequent betas, RC's when closing in on release"
  * A clear policy on the release, Ideally, My preference would be that the  
last RC must be in the wild for at least 2-3 days, with no further commits  
before release
    * If a commit is required, next RC and repeat this step

Trac:
  * A clear policy documenting how patches must be tested
   * Edge cases need to be checked, not just that the PHP executes.
   * Its obviously, impossible that every patch will not introduce a bug,  
and its not always possible to explain in depth the ways in which  
something has been tested.
  * What "Feature requests" should be discussed.
   * Its my opinion, That no feature request should ever be opened on trac  
first, should be brought up on wp-hackers or the support forums first (Or  
another location with lots of WP'ers. or Unless it has been put past a  
core developer who strongly supports it)
  * Respect & proper use of trac keywords
   * Most people dont have a problem with this, But for example, marking a  
bug as tested without properly testing (Or posting how it was tested) or  
setting other keywords which some developers use
    * For example, The 'early' keyword used to keep track of a punted  
ticket from a dev. Normal users should use 'commit' to add it to the  
Commit Candidates list
   * Denis's new trac reports based on the keywords are great, and they  
rely on the keywords, so having these set properly greatly increases  
efficiency.
  * Potentially a better Component list.
   * Bugs might surface in say the Template system, but its actualy the  
Taxonomy system thats the problem
   * Bugs affect multiple locations.. a multi-select heirachial list could  
be better, Would help seperate Plugin Upgrade issues from Database Upgrade  
issues for example.

More In general:
  * I think people need to realise when they're solution is not best, I am  
myself guilty of this, and so have many others. I've seen too many people  
flood trac/wp-hackers without reconising what could potentially be their  
mis-understanding of a problem, the suggestion, or to be fair, sometimes  
may not have a indepth knowledge of the issue to understand the effects of  
it
   * So i ask people to think of that next time in an arguement, try to  
keep your mind open, Even if it goes against every bone in your body to  
even consider the other approach, it pays off to at least look it over.


Some of these items are already done, some people may not realise it  
however, having them displayed more prominently may help with that..



-- 
Dion Hulse / dd32

Contact:
  e: contact at dd32.id.au
  msn: msn at d32.id.au
  skype: theonly_dd32
Web: http://dd32.id.au/