[wp-hackers] The problem with Contributions and This Thread

[Jacob Santos]

Thread in Question:
http://wordpress.org/support/topic/what-should-2011-hold-for-wordpress

The Point In A Nutshell: WordPress is community driven, meaning I write a
patch and it is either debated, audited, tested, committed or any
combination. Someone saying, "I want this feature or this feature," has
never mattered, unless there is a patch or a lead developer jumps on and
develops the feature. Given the limited amount of lead developers and the
allocated time they have, much of what goes into WordPress has historically
been from the community.

The thread is a waste of time, since as a contributor, unless I care about
what some Joe writes on a thread or what some ticket is in Trac, I'm going
to do my own thing. This is true even if I write a patch for one of those
thread features or for some ticket on Trac.

The Problem:

The basis for setting a roadmap is for planning features. If WordPress.org
is going to continue along the path of planned features, then its release
cycle will need to be extended or allow for features to incubate until they
are ready for inclusion in core.

In a community based development, the planned features has been and will
always be what contributors decide. It is great to say, we want feature A,
B, and C. The problem, at least from my point-of-view is that saying, "Well,
this isn't on the roadmap, so it isn't going to get in," causes a clash of
reality. WordPress.org Foundation or Automattic or the Lead Developers want
feature A, B, C, etc, then have them work on it full time.

Having a roadmap for Lead developers is great, but the development cycle
requires accepting features from outside the lead developers and roadmap.

Problems I'm Seeing Personally:

* Weekly IRC Chats are limited to Agenda.

I can't count how many times I wanted to bring something up and be told that
I may not. Hello, potential and former contributor speaking here, if I'm
wanting attention for a feature that has been ignored and is tested and
commit ready, then where am I supposed to bring this up? On Trac, I'm
ignored, in WP-Hackers, I'm ignored partly because of the noise and partly
because very few lead developers participate of any real time to the
threads.

* Lead Developers for some reason have been limited to a certain scope
within the development of WordPress.

So basically, I'm relying on a lead developer whom I must receive blessing
from and must rely on their time, input, and commit to my issue. For me
personally, I've given up on ever getting my patches in that area committed.
In fact, I'd rather you removed my patches, even the tested and commit ready
ones, because I'm no longer going to be updating or supporting them based on
feedback.

If you want me to contribute, then I need less, "This isn't in my job area,
therefore I'm not going to help you," and more, "Well this has been tested
and is ready to go."

Really, it reminds me of my first patch, where I had a hell of time trying
to get a lead developer to even look at the issue let alone get someone to
even commit the fix. I was almost never going to contribute to WordPress
again after that. This time it is even worse, because I'm depending on not 5
to 7 lead developers to find time to look at my patch and commit it, but
one. One that doesn't appear to be interested and thus, I'm SOL.

* Corporate Attitude and Coordination in Community Driven Development.

Okay, I must say that this appears to work fine in Apache projects, Zend
Framework. However, I'm seeing similar problems creep up that CodeIgniter
community was / is having. People are / were leaving that project, because
their contributions weren't being made into the project fast enough. They
are solving that in part by splitting the development off in a community
driven (unstable) and a company driven (stable) branches. Similar, I might
add to Zend Framework, in that they have an incubation period for new
components.

The desire to have a community driven development requires the openness to
accept patches outside the limited scope of planned features. Not only
limiting to defect fixes, but also enhancements and features. Unless a lead
developer desires to spend the time working on a feature himself or herself,
then the community will determine what they work on based on variable
factors and some won't even realize or care that there is a planned list or
roadmap.

Telling a potential or existing contributor to bugger off will lose points
and potentially lose contributors.

* Contributors have projects, a life, a job, etc too.

Respecting the time of the contributor also must be weighed as well. I
realize that lead developers have their own projects, their own time
commitments, their own life, etc. What needs to be weighed, always, is the
contributor time factors as well. As it has been since the beginning, the
time I devoted to WordPress.org has pushed other projects to the wayside. I
must weigh contributing to WordPress.org verses working on my own web site,
my own projects. If a patch is brushed aside, my commitment to WordPress is
diminished. Continue this trend over time, and I will all together stop
contributing.

* I might be the biggest Jerk on the Earth.

Respect. Learn it, live it.

If I'm being a jerk, it is most often because I'm angry about something. If
I'm a contributor, then do find out what it is and if my attitude is
unwarranted, then take appropriate action. If I'm shown respect first and
foremost no matter how bad I act, then I will shape up or move out. If not,
then follow Poisonous People and respectfully ask that the person to not be
part of the community.

Losing one jerk is not a big deal. Not being able to tell who the jerk is a
problem.

* As a contributor, All I Care About is my patch

This might not be true for the major contributors, but one thing I've
witnessed triaging Trac is that this should be considered a rule, if it
isn't already. When there were 3 active lead developers and the patch load
was heavy and personal features were being worked on, many patches went
stale. Many original patch contributors moved on after several weeks or
months.

In a project where there are possibility 2 contributors for every 1 that
leaves (a hyperbole by the way, it is more or less closer to 1.05 to 1.25),
meh, it doesn't matter. One leaves and another replaces. That is part of
what makes WordPress.org great.

* I Should Never Have to Beg

If this needs an explanation, then you fail.

The only time I should need to follow-up on a patch or ticket, is when there
is feedback saying that the patch doesn't work or isn't commit ready with
some reason why.


Jacob Santos

PS: I have been wanting to write this for a long time, but I always feel
that I'm off-base doing so. My experiences surely is not representative of
the whole? However, what might have been a minor problem years ago, has in
my opinion escalated. I have seen others give up being a contributor and
seen the reasons behind it.

I know Jane Wells means well and I believe she is coming at this from a
corporate point-of-view. However, I'm surprised at the corporate attitudes.
Is this a community project and if so, then meritocracy should not be part
of it or at least have a concise definition for WordPress Foundation.

PSS: It appears being part of the meritocracy does not include dissent and
being a jerk (if even a little), so if you fall into either one of those
categories, then you need not apply.