[wp-hackers] Improving the mailing list. (Was Auto Update Plugins)

[Stephen Rider]

Peter --

Reading the wp-hackers list description in the Codex:

"The wp-hackers list is meant for people interested in extending  
WordPress either through plugins or improvements to the core code.  
Serious discussion that determines the future direction of the  
WordPress codebase takes place here."

Sounds like the stated purpose of this list is to discuss, among other  
things, what should and shouldn't go into core.  Certainly discussion  
regarding making plugins is part of that description.

It seems to me that different people have different ideas as to the  
purpose of this list -- but even if the original purpose of the list  
was something different, you can hardly blame people for reading the  
above and thinking that discussing plugins or "improvements to core  
code" was somehow inappropriate.

Responding to your list...

On Feb 20, 2009, at 4:31 PM, Peter Westwood wrote:

> I think what this mailing list needs to do is to try and follow the  
> follow list of ideals (intentionally not complete):
>
> * Focus on the technical aspects in the discussion.

Yes, but you also need to pay attention to "the technical aspects of  
*what*?"  You have to decide what you're doing, in addition to the  
details of how.

> * Think about the users - not just what you think is right - It is  
> very hard for a developer to understand the end-users viewpoint.

This seems to contradict the first somewhat.  Are we talking about end- 
user experience or the under-the-hood technical details?  Answer to me  
is: both are appropriate.

> * Address real world problems

Entirely agreed.

The "auto update plugins" discussion that incited the exodus was a  
legitimate discussion, I think, but went on WAY too long.  However, I  
think the biggest problem was the attitude that "nobody needs to do  
that" -- obviously somebody does, or it wouldn't have come up.  The  
question was what the best way would be, and it somehow turned into an  
ego contest.

> * Provide examples - if there is something you think you can't do  
> shows us what you have tried to do, shows the plugin/core code you  
> have written that you can't get to work.

That sentence needs a rewrite.  Do you mean if we try and fail to  
write a working patch, show the failed path and maybe the list can get  
it working?

> * Try to avoid arriving with a just a solution.  You need to be able  
> to express the end-user issue as well as the reasoning as to why the  
> solution you propose matches it best.

...keeping in mind that sometimes "end users" are plugin authors or  
fellow core coders.

> * Work with the project philosophy not against it

Meaningless without defining it.  Obviously many different people have  
very different ideas as to what the "project philosophy" is.

> * Release early, release often - If you have an idea that you think  
> is core worthy raise a trac ticket write a simple patch which  
> demonstrates the solution

Sometimes "solution" patches aren't so simple.  That is *exactly* why  
people often want to come here first to see if the work they put into  
a patch will go anywhere.  Perhaps as a committer you lose sight of  
that a bit.  You have "God's ear", the rest of us don't.

> * Avoid bikesheding

I think that's spelled "bikeshedding".  (*ahem* sorry... ;-) )

> You friendly core committer, patches always welcome.

Who are the other core committers?

Stephen

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