WP Suggestions – Keep it clean

I dont think there is something new here to WP developpers ??

The approved hacks thing is kind of new. There is a thread called approved hacks, but no approved hacks section.
Approving a hack could be very tricky business though. Couldn’t it’s behaviour depend on how it is used? I wonder.
The plain vanilla WP is standards compliant, which is an laudable acheivement, and we should be thankful for that. ??

Plugins could be checked and approved by a fairly simple process:

• Does it have documentation which explains it purpose, its use, and its installation /configuration process?
• Does the plugin produce web standards-compliant XHTML and CSS (if used)?
• Does plugin follow do what it is designed to do reliably?

I suggest these guidelines and the “approval” process as I have seen other weblog software suffer from “hacks” that are poorly coded, documented, etc. Users complain, and the complaints then get directed back to the weblog software.
It’s important to keep in mind that not all weblog users are coders, hence the benefit of well designed and documented plugins.
Probably a good idea to identify plugins that are excellent, and also recognize – through not gaining approval status – those which are not.
<rb>

I would agree with all those points except the one about bug fixing. Most users here would rather the devs concentrate on introducing new features than cleaning up minor bugs. That’s the users responsibility. I also don’t see the point in documenting plugins. The main software doesn’t have much documentation so why would it be necessary for add-on hacks?

Will, perhaps I’m giving you too much credit, but I can’t believe that *you* actually believe some of the crap you write.

The main software doesn’t have much documentation so why would it be necessary for add-on hacks?

I guess it’s a matter of perspective. Documentation adds to the level of professionalism of a product. I see here that there’s already concern/interest in creating more complete documentation for the weblog software itself. So, now that the plugin mechanism is in place in 1.2 (I’m not talking abut “hacks” – that’s has been discussed elsewhere) it seems a perfect time to think about how to better provide plugins for WP’s userbase, existing and new. WP now has a “plugin” interface, so it has moved out of the “hack” mode, it seems to me, and into the rhelm of providing a more formal interface with which to extend WP’s basic capabilities. That’s why this is a great time to consider how WP will handle the plugins.
As to whether or not it’s the user’s responsibility to fix bugs, of course I disagree with this. I understand that WP is open source, but I don’t think that means “unsupported” or “buggy until you fix it on your own”. That’s just silly. The user community will of course fix bugs and offer improvements to the code; that’s open source. But requiring a user to fix bugs is not the making of great software.
Again, I think it’s a matter of perspective. From my perspective, WP has the opportuity to go down a road that many other weblog packages have not. That of course is not up to me; I am merely making a suggestion that WP consider how it approaches some aspects of how it handles users.
<rb>

Users always want more features. Add this, add that, followed by me too, me too. One of the primary jobs of a maintainer is saying no to features. Otherwise you end up with Microsoft product.

Since it is mentioned here, might as well post my suggestion for plugins. But first, submitting a plugin is vastly different than developing a product. The documentation for WP should be as great as the program itself and, no offense, but I have rarely met a programmer who could write instructions as well as he/she could write code. Perhaps some of those here who would like to contribute but don’t program could form their own “development team.”
Anyhoo, my suggestion: I already have 8 plugins and I can see that having instructions in the description is going to be a bit much. Perhaps the instructions could be posted somewhere (wiki?) and a link to it placed in the description?

Cena: just because I don’t think your little documentation project is the single most important part of the WordPress effort doesn’t mean I’m talking ‘crap’. And the emphasis has always been on providing new features rather than bugfixing. If bug fixing was a priority we would have a bug tracker and probably still be on version 0.72. Are you really saying you would prefer that state of affairs?

Will, there is no correlation between your crap about the docs project and your unfounded statement that I think it’s ‘most important part’ of WP. Ridiculous. Even if *I* did think that (which I don’t), it would not negate the fact that docs are a necessary part of any project, whether *you* happen to need them or not.
Further, there’s no correlation between bugfixing/tracking and the need and/or importance of a docs project. Your arguments simply don’t make sense.

WordPress is right in the middle of a significant architecture change. Based on this, it doesn’t make a lot of sense to focus on bug fixes on the old architecture — 1.02 — when they should be focusing on the new architecture and putting this product out.
After that, it makes sense for them to provide bug fix releases (smaller version releases, such as 1.21, 1.22, and so on), in addition to major new feature releases (such as 1.3 2.0 and so on); otherwise WordPress will never be a comfortable application for non-tweakers.
But the management of software going through these ‘dual’ activities is always interesting. Even with CVS to help. A bug fix database is going to be essential at that point.

I guess we have to quit this “Us” and “Them” attitude first, to set things right. This is an opensource project, and we are all free to contribute. We can find and fix bugs, write documents explaining what we find difficult, documenting answers we know, and help make this better. Since we are not asked to pay for a software product that has had many man hours put into it, the least we can do is contribute a few hours of our own. I beleive I read somewhere in my Software Engineering book that “Software is only as good as it’s documentation”. That might be true to a certain extent, and there is a vacuum in WordPress documentation, so come fill it!
Let’s all be optimistic and hopeful, and contribute whatever little we all can to make this better.

WP should have a bugzilla or mantis installation running… ??
-d

@shelleyp: I totally agree with your suggestion about the lack of a bug tracking system.
In fact, I brought the topic up myself once, in this thread, and the reasons given for not having such a system in place left me with nothing to say, since I think there are very few active developers and the developers need to concentrate on the priorities for the project. I cannot make up their minds for them ??
I cannot, unfortunately maintain a bug tracking page, because I am new to php, MySQL and the other technologies related to this project, else I would have pitched right in, and said I could help. That said, I hope the idea is at least in the stack, and will be addressed sometime.

About plugin documentation: Take a look at any plugin (mod, to be more precise, because it doesn’t have a plugin architecture to be honest) for PunBB, i really like the kind of installation instructions provided. Every plugin doc follows a standart layout for instructions, it eases a lot the learning for the end-user (that’s me).
I like the idea of a approved plugin seal – i have tried to install a few hacks, and i had a success rate of about 50% (i sware i am not THAT stupid, i CAN follow even covoluted instructions: some hacks just don’t work, and a few need a lot of guessing to be forced to).
Not complaining about the hacks at all, but a seal would raise the standarts.