[wp-hackers] Improving the mailing list. (Was Auto Update Plugins)
wp-hackers at striderweb.com
Sat Feb 21 14:50:02 GMT 2009
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
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
> * 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
> * 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?
More information about the wp-hackers