[wp-hackers] Putting the P in WordPress

[Stephen Rider]

Eric's write up was excellent.

On Jul 6, 2010, at 3:12 PM, eric at eamann.com wrote:

> Unfortunately, this is where the conversation begins to derail.  Let's try not
> to make it a personal issue.

I laughed when Matt said we were approaching Godwin's Law. :-)  Some of the rhetoric is getting a bit overwrought, but for the most part I think it's remained pretty civil.

> We're facing three core problems here (that I've
> seen at least):
>  
> 1) WordPress has added a feature that modifies post content without input or
> oversight from end users, many of whom are not technically skilled enough to
> program or install a work-around.  This is a question of perceived censorship
> because the platform is now actively changing the words you originally wrote
> without your permission. (Philosophically I see this as a large issue.)

This is a big issue.  The thing for Matt et al to remember is that in this case the *perception* among the community is as important as the issue itself.  The Core committers are skirting the idea that in the end, what the community wants doesn't matter.  Significantly, this is not the first time that personal preferences have simply overridden strong opposition.

1) A lot of people want to get rid of Hello Dolly (personally a non issue to me).  There was a lot of discussion on this one, but ultimately it was Matt's baby and so it stays.  Mat said in one of his replies that so-and-so clearly didn't understand the intent of Hello Dolly.  He's right -- I think most people don't.  Again, not a big deal to me, but maybe that should be made more clear?

2) The obfuscated code for the "blue pill" easter egg.  Even after someone pointed out that with this code in there, ***WordPress is no longer GPL2 Compliant***, it still ended with "Matt likes it there, so it stays."  What the heck?  We can't even un-obfuscate the code?  Really???

Keep reading before throwing out all the "That isn't how it was" arguments...

> [...]The most resounding issue, though, is the lack of openness in discussions here
> on the mailing list.  It doesn't matter who you are or how you're affiliated
> with the WordPress project, you can have an opinion.  Further more, that opinion
> can be wrong.  That's what makes working on a project like this productive - you
> voice your opinion, discuss it with the community, and come to a conclusion
> about the best way forward.  Your initial idea may or may not be the final
> conclusion.  
>  
> To forego this discussion before committing code, though, threatens to destroy
> the process.  Community members who thought themselves your equal now feel left
> at the side of the road.  Dismissing concerns out-of-hand only reinforces this
> feeling and causes a minor issue (the entire patch was ~5 lines of code!) to
> escalate to an emotional, major one (we've been debating this for how long?). 

Yes, Yes, and Yes.

Matt et al, what you're missing is the point of perception.  This has become a matter of principle for a lot of people who contribute to WordPress.  Yes, this is a community project, and yes, communities need leaders.  But when those leaders abuse that authority, you really start causing trouble within that community.  Adding in little chunks of code that please you on a personal level is an abuse of that authority.  You Can !== You Should.

Here's the question that nobody supporting this patch has answered, though it has been asked many times:  Does this patch serve the User, or does it serve the Software?  Hint:  it does cause problems -- with web sites and as a matter if principle --  and other patches have been rejected on a basis of **far less* opposition than this one.  Any other patch would have been reverted by now, but somebody somewhere *wants* it there

As I've said before, this could be done in a way that serves the User.  The best suggestion I've seen is that this simply should be a "spell check" thing -- indicate to the author that there's a misspelling, **but don't force the change**.

> [,,,]I'd like to suggest that we take a minute to cool down and think about what's
> really at issue here.  Are we upset about a patch?  Are we upset about an
> inconsistent commit process?  Are we upset about the dichotomy between core and
> non-core developers?  Then, without insulting one another, injecting snide
> remarks, or claiming that people can "vote with their feet" and leave a project
> they love because of a ~5-line patch, let's figure out what we can learn through
> this process and how we can avoid such a massive public backlash in the future.

I've tried to avoid making this personal, because it really shouldn't be, but...

Yes, Matt, saying "You can just leave" is just wrong.  It's arrogant and dismissive.  It's "Too bad, I'm gonna do what I want" with different wording, and had no place in this discussion.  I doubt that's at all what you intended, but that is the clear implication of that kind of statement.  Nobody is going to abandon WordPress over this, but that doesn't mean the change was okay.

> For what it's worth, I'd like to see:
> - This filter turned off (I'd rather write a plug-in to *add* a filter than
> *remove* one)
> - A clear, concise list of what steps *everyone* must follow when submitting a
> patch to core

A big Yes on the second one.  Unless there is some huge bug that needs to be fixed ASAP, nobody should just be sticking code into Core without discussion.

> I don't know about everyone else, but I'd be more than happy with either or both
> of those ... 

Both for me, but ultimately I guess I'd be happy if it simply didn't keep happening.

Getting personal again for a moment:  Matt -- I respect the hell out of all you've done for this project and for Open Source in general.  That is quite frankly why "Hello Dolly" doesn't bother me, even if it is mainly "Matt's Baby".  Fine -- the Guy In Charge just wants it, and it doesn't harm anything.  Let him have it.</personal>

Regarding the obfuscated easter egg code:  In discussion of the "Wordpress" filter, the main defense is that a one-line plugin can turn it off.  Great.  But that flies in the face of the fact that we have retained obfuscated code in Core despite opposition to such, where the obfuscation is there solely for the purpose of making it difficult to figure out what the heck is going on.  When someone pointed out that obfuscated code is not allowed under the GPL, that should have been the end of the discussion right there -- get rid of it.  Instead, somehow, all that discussion had absolutely no effect, because Somebody, Somewhere, wants that code in there.  And that is what makes me think that "you can turn the filter off with a plugin" misses the point.  These two things are part and parcel of the same argument.

-- 
Stephen Rider
http://striderweb.com/