[wp-hackers] Putting the P in WordPress

Tue Jul 6 21:49:21 UTC 2010

Chip,

Forgive me if it came across as if I was addressing you specifically.  You
weren't the first to take that tone with your post, it just happened I was
engaged in an off-email debate at the time your message came through so it was
the one that I responded to.

There have been more than a few snarky comments in this thread, and more than a
few of those have been directed specifically at Matt ... that's what I was
responding to.  Yes, he wrote the patch and yes, he's been the most vocal
defender of it.  But keep in mind he's not the only person responsible for the
patch making its way into core (Nacin committed the patch, and at least one
other core dev has commented in this thread already).  The overall tone of
things feels like it's taken an anti-Matt turn rather than an
anti-this-specific-patch tone.  That's not OK, and that's what I was responding
to.

But yes, your point is valid.  If plug-in popularity is the metric against which
patch suitability is measured, then this patch fails in all regards.  There are
hundreds of more popular plug-ins in the repository, and most (if not all) of
them have little to no chance of making it in to core.  But to argue for plug-in
popularity as the rule against which we measure for either inclusion or
exclusion is to pass the buck and bow out of the discussion.  Keep in mind that
many people are unable to run plug-ins either due to their hosting environment,
server setup, or sheer inability to implement the new systems.  Using download
rates as a way to measure relative "success" of one patch or another is IMO an
inherently flawed idea.

But again, forgive me if I came across as targeting your remarks in particular.
 That wasn't my intent at all.

~Eric

On July 6, 2010 at 8:52 PM Chip Bennett <chip at chipbennett.net> wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers