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

[Peter Westwood]

On 21 Feb 2009, at 14:50, Stephen Rider wrote:

> 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.
>

I still think that description is appropriate.  I was trying to focus  
on the way in which discussion occurred more than the subjects of  
discussion.

> 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.

What I mean here is that we should focus on the technical reasons why  
one implementation method is better than another - for example easy of  
implementation, easy of use etc.

>> * 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.
>

Both.  But also simplicity, safety and obviousness in terms of UI/ 
Behaviour

>> * 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.
>

For me the biggest issue in a thread like that is when the discussion  
moves away from being technical and moves on to egos and bikeshedding

>> * 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?
>

Yes.  I find it intensely frustrating when someone raises a ticket on  
trac, or sends an email to this list of the following flavour - "The  
<blah> filter/action doesn't work.", "RSS feeds are broken" but  
doesn't provide any detail on the issue like the code that doesn't  
work.  Especially when looking at the code it is possible for me to  
write something using the action/filter which does work.

>> * 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.

Yes.  The important thing is bring me the problem not just the  
solution.  I need context to understand severity and why the proposed  
solution is the best way to do it.

>
>
>> * 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.
>

See my other replies.

>> * 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.
>

I know solution patches are not always simple.  And I also understand  
the frustration of writing a patch to see it languish in trac and not  
get committed - it was not that long ago that I was in the same  
position.

If you want to help get your patch committed you need to make sure  
that it is obvious what it fixes so that I can test the fix, and join  
us in #wordpress-dev and promote your patch if it languishes (or CC my  
user id on the patch in trac to get my attention)

westi
-- 
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5