[wp-hackers] WP Management (was: WordPress Openness)

[Brad Fults]

I have followed this entire discussion and I have to say that I felt
the same things that Mike Little has expressed. You did make a request
about the direction of development, Matt, with your "1.5.2 or on to
1.6?" post, but much of that discussion went untouched and was never
met with an adequate response (IMHO). This wasn't an isolated
incident, but rather a trend.

Many of the issues addressed in this current discussion, especially
those in reference to SVN access and code changes, were already
addressed by my reply to Matt's aforementioned post, but I received no
replies.

I will re-post my response verbatim here and open it up to discussion
under this new light, as many of the issues I was anticipating have
indeed come under the microscope and I think there might be some value
in my suggestions or it might at least spawn some constructive
discussion:

Firstly, I think the bug system needs to be stabilized and organized
before any talk of development progress is made. A custom field needs
to be added to the new ticket system in Trac for a "Patch?" boolean.
At that point, all bugs that are assigned and have patches should be
immediately committed and tested for a 1.5.2 release.

After that, a huge effort needs to be put into assigning,
prioritizing, and triaging the bug list [1]. I don't know exactly how
many people have privileges on the bug system, but it seems to be a
very small number. I think the team needs to allow more people to help
with triaging and organizing in Trac. "Bug days" like those over on
irc.mozilla.org could help this process along greatly.

Also, I think it would be good to set up a "review" and "super-review"
system whereby contributing developers can get their bugs approved by
core devs and can commit their own changes to the tree. Having only
two developers commit changes makes development slow and disorganized
and I think WordPress needs to look ahead to the future where there is
a much larger developer community behind it. Of course in the meantime
it would still be simpler with only Matt and Ryan committing if they
could pull up a list of all bugs with a patch and r+sr, allowing them
to commit and move on to the test cycle.

After the bug system is worked out, all of these new features in the
Version 1.6 wiki entry can be added to Trac and prioritized.

With a stable 1.5.2 release behind us, we can then start to make the
larger changes slated for 1.6. I do think that we should definitely go
toward 1.6 and maintain backwards-compatibility, however. Software
that breaks b-c too often and increments major version numbers
regularly ends up in a bad position (v13.0 sucks).

In summary, I think we need organization and a clear set of goals and
development processes before moving ahead to the next release. (Just
my four cents.)

[1] - http://trac.wordpress.org/report/1

-- 
Brad Fults
NeatBox