[wp-hackers] Putting the P in WordPress

Chip Bennett chip at chipbennett.net
Tue Jul 6 20:52:39 UTC 2010


While I admit that I might have added unnecessary snark into that reply* (and 
apologize for doing so), is the point invalid?

I wasn't the one to bring up the issue of popularity of a plugin as 
justification for decisions regarding core code; I believe Matt brought that 
up (in reference to determining whether to consider removing the filter from 
core, based on popularity of a plugin to remove the filter).

But, a plugin to *add* the filter has existed in the repository for three 
years, and has been woefully unpopular - it has generated only 334 downloads.

So, does that mean that if a plugin to remove the now-core filter exceeds the 
popularity of the extant plugin to add that filter, that the core filter will 
be removed, and left as plugin material?

Or should this really be left to a plugin popularity contest to begin with? I 
would suggest that the relative lack of popularity of Ozh' plugin is prima 
facie evidence that the functionality should never have been considered as 
core material in the first place.

* p.s. Snark: yes. Personal attacks: no. You'll find the former in my reply, 
but not the latter.

-- 
Chip Bennett
chip at chipbennett.net
www.chipbennett.net

On Tuesday 06 July 2010 3:12:49 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.  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.) 
> 2) Performance issues: Adding another filter slows down the processing
> engine. (In the short term this seems to be a minor issue.)
>  
> 3) Standards and consistency: For a community member to submit code to
> core, they must create a Trac ticket, submit a patch for discussion,
> possible tap a core developer for feedback on IRC, and wait for several
> rounds of feedback before it can be added (I'm talking feature additions,
> not bug fixes).  In this case, though, a core developer submitted a change
> to core code without the same levels of discussion.  (This presents a much
> larger issue.)
>  
> WordPress is a community project.  It's used by the community, supported by
> the community, and (allegedly) developed by the community.  When the
> community is required to submit to multiple layers of review, allowing
> core developers to circumvent that system creates an environment of
> animosity (just read back through this thread if you don't believe that).
>  We begin attacking one another on a personal level rather than opening
> discussing the issues and trying to build a stronger community.
>  
> The fact of the matter is that this filter is a somewhat trivial issue.
>  Did it break a few sites?  Yes, but any problems can be quickly fixed by
> a competent developer and many of us are willing to help community members
> overcome problems like this for free.  Any upgrade can break a site, so
> this isn't a big surprise. 
>  
> But did this patch follow the set standards for patch submission? ( see
> http://codex.wordpress.org/User:HEngel/How_To_Become_A_WordPress_Developer
> or http://codex.wordpress.org/Development_Planning)  No.  That's where I
> have the biggest complaint.
>  
> 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?). 
> When new developers want to add a new feature to core, they're encouraged
> to first build a plug-in and to see how popular it is with other users.
>  If it's a major improvement, someone will suggest it be added to core.
>  In the case of this particular patch, I can't see many people installing
> a plug-in to add just this feature.  Still, engaging the community
> *before* adding the patch would still let everyone know about the feature
> and gauge its popularity. 
> Had we polled even just this list before, I have no doubt many of us would
> have jumped on board.  We didn't, and it's time to learn from that slight
> oversight and move forward.
>  
> What non-core devs are seeing is a unilateral modification of code by core
> devs without the approval process those same core devs require from the
> community. It has us up-in-arms about the patch, and struggling to grasp
> at an amicable solution.
>  
> 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. 
> 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
>  
> I don't know about everyone else, but I'd be more than happy with either or
> both of those ...
>  
> ~Eric
>  
> 
> On July 6, 2010 at 7:40 PM Chip Bennett <chip at chipbennett.net> wrote:
> > Oh, silly me!
> > 
> > There already *is* such a plugin. It's been in the repository for almost
> > three years:
> > 
> > http://wordpress.org/extend/plugins/ozhs-correctly-spell-wordpress/
> > 
> > It has a grand total of (wait for it...)
> > 
> > *334 downloads*
> > 
> > So, Matt, tell us again: just how vital and popular is this core change?
> > 
> > --
> > Chip Bennett
> > chip at chipbennett.net
> > www.chipbennett.net
> > 
> > On Tuesday 06 July 2010 1:34:09 pm Gavin Pearce wrote:
> > > +1 :)
> > > 
> > > -----Original Message-----
> > > From: wp-hackers-bounces at lists.automattic.com
> > > [mailto:wp-hackers-bounces at lists.automattic.com] On Behalf Of Chip
> > > Bennett
> > > Sent: 06 July 2010 19:29
> > > To: wp-hackers at lists.automattic.com
> > > Subject: Re: [wp-hackers] Putting the P in WordPress
> > > 
> > > How about moving the entire function itself into a plugin, and see how
> > > many
> > > downloads *it* gets?
> > > 
> > > > On 7/6/2010 10:33 AM, Harry Metcalfe wrote:
> > > > > I wrote a patch weeks ago to take it out. I'm really not trying to
> > > 
> > > be
> > > 
> > > > > difficult! I just think this filter is a terrible idea. And it's a
> > > > > little sad to witness the total lack of interest from the core
> > > > > team. This isn't how it's supposed to work, IMO.
> > > > 
> > > > Maybe write and promote a plugin, and we can see how many downloads
> > > > it gets?
> > > 
> > > _______________________________________________
> > > wp-hackers mailing list
> > > wp-hackers at lists.automattic.com
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > > _______________________________________________
> > > wp-hackers mailing list
> > > wp-hackers at lists.automattic.com
> > > http://lists.automattic.com/mailman/listinfo/wp-hackers
> > 
> > _______________________________________________
> > wp-hackers mailing list
> > wp-hackers at lists.automattic.com
> > http://lists.automattic.com/mailman/listinfo/wp-hackers
> 
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers


More information about the wp-hackers mailing list