[wp-hackers] Improving WordPress Core Development

[Ryan Boren]

On Tue, Dec 29, 2009 at 1:36 AM, Dion Hulse (dd32) <wordpress at dd32.id.au> wrote:
> 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:

Agreed on your points.  I'll start by roughly documenting what we
already do, or at least try to do. Let's begin when opening up on a
new release. Here comes the alpha stage:

** Alpha **

* Collect feature ideas from ideas forum, support forums, most popular
plugins, dev brainstorms, and other sources.
* #wordpress-dev meetup to decide on which features we want to commit
to and set the scope of the release
* While this is going on, do some trac gardening of things that got
punted from the previous release. We're pretty bad about this
sometimes, but with 3.0 Peter and I have been going through some of
the backlog.
* With features decided, create "task" tickets for all features
targeted for the release.  Set existing "enhancement" tickets that
made the cut to "task". Start developing and submitting patches to the
tickets.
* At the same time, more trac gardening on existing tickets.
* Continuous integration in trunk, committing feature work early and
often.  Trunk may break at times, but we're all dogfooding the latest
bits.

** Feature Freeze **

* Once all features are deemed complete via meeting on #wordpress-dev,
we enter feature freeze. Sometimes we have features that aren't quite
ready that are noted as exceptions to the freeze.  Everything else is
put in feature freeze with the hope of driving to beta on everything
else.  Ideally, there would be no freeze exceptions.
* Drive to remove all beta "blocker" bugs in prep for entering the beta cycle

** Beta **

* "blocker" tickets are cleared.  Beta 1 is released to kick off the
public beta cycle.
* Fix bugs and start punting enhancements.
* Release Beta 2 about a week later.
* Fix bugs and start punting less severe tickets.
* Release Beta 3 a week later.
* Punt everything but blockers and fix those blockers.

** RC **

* Release RC1
* Wait x days. In the past this has been from 1 day to a week or so.
* If more bugs, release RC2. (We haven't done this in awhile).

** Final Release **

* Release it
* Monitor feedback and start collecting fixes for a maintenance release.

** Alpha **

* Do it all again for the next release.