[wp-hackers] Improving WordPress Core Development
Dion Hulse (dd32)
wordpress at dd32.id.au
Tue Dec 29 07:36:37 UTC 2009
On Tue, 29 Dec 2009 07:31:46 +1100, Dan Cole <wp at dan-cole.com> wrote:
Sounds good to me, Here's my long brainstorm of some changes which could
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
I see a few things that WordPress needs:
* A clear policy on what types of patches goes into what release,
specifically, point releases -
* A clear policy on when the last enhancement ticket gets commited
* 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
* 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
* If a commit is required, next RC and repeat this step
* 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
* 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
* 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
e: contact at dd32.id.au
msn: msn at d32.id.au
More information about the wp-hackers