I dont think there is something new here to WP developpers :)
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:
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.
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.
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... ;)
@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.
When you have something to actually offer besides snarky comments and superior attitude (but very little of substance), do let the rest of us mere mortals know.
Took the words right out of my mouth. You have made three posts in this thread and none of them have been useful, constructive, or even on-topic. If you wish to make childish personal attacks, please make another thread for them or post them on your own site. Nobody here cares.
To all those saying we need a bug tracker; Matt has already made it clear that's not going to happen because the devs are too busy as it is. This demand reminds me of all the pointless threads about wanting to change the forum software. If you want something done it is up to you to do it yourself.
Good product by good people -- but I get the impression that the internal code of the tool is hands off except for the vetted developers.
"Too many cooks..."
Limiting the development team is one of the best ways to ensure there is consistency in the underlying coding standards of a project. Having consistency is one of the ways to limit bugs and feature creep.
Back to the issue of "plugin approval" - here is where additional development, outside development by those who want to add value and features to WP which are not present in the core code, comes in.
From my perspective, I'd rather have a solid, standards compliant core set of weblog tools available, along with the extensibility of a plugin system. I'd rather modifications to the core weblog tools come in the form of well designed plugins, rather than "hacks" to the core.
The former will produce a much more reliable system than the latter. Plus, I can install plugins to give me the features I want, and leave out the plugins that contain features I don't need.
Well, then, I guess the developers are just going to have to fix the bugs and do the documentation. After all -- we'uns wouldn't want to track dirt all through their nice clean code and documentation.
To the thread at large:
You become a developer like you do on any other project. Contribute bug fixes, rework patches when asked, demonstrate that you can work with the maintainer, and show some commitment. Eventually, you will be trusted with CVS access. Good code will not be turned away. You become a developer by doing.
The bug tracker issue is something that gets debated to death on every project. I've been there a dozen times. Just read the Linux kernel mailing lists for some lively discussion on the topic. The simple fact is that unless someone actively manages it, it quickly becomes a worthless mess that developers won't bother with. Debating proper software process isn't going to motivate developers to sink their time into marking bugs as duplicates of each other all day. The community needs to step up. It does take people doing the unfun tasks to make a project successful. Anyone can feel free to start doing them instead of asking others to do them. I do lot's of unfun stuff when I fix bugs on features that I personally never use or when I mark strings for translation for hours on end. Someone else can help with the unfun stuff that I don't want to do. So, we can talk about bug trackers all day, but that won't get us anywhere. Someone has to care enough to not just ask, but to do. Who wants the pain of managing it? It would have to be someone who doesn't know what they're in for. ;-)
Randy, I think you have nothing to worry about with the future of WordPress.
2fargon, approved plugins will be those that work elegantly, adhere to the coding guidelines, and follow web standards. This will be fleshed out more when the plugins section on wordpress.org is done.
Sushubh, I do test in Opera every now and then. Besides the advanced edit screen problem, which is an Opera bug (or difference in interpretation) everything seems groovy.
WillM, we are committed to fixing bugs as well as providing excellent documentation.
rboren, totally agreed.
Beel, there's no reason a plugin can't link to the wiki or other external documentation. In fact it's recommended.
Shelleyp, in the past we have provided bug fix releases even though development had moved on to the next major version, and we will continue to do so in the future. It 's not too hard on developers.
David, the reasons a bug tracker is not being set up currently have been covered elsewhere.
Anatman, the problem with complicated instructions is that what is line 115 in a vanilla install might turn into line 177 after you install mod #1, and then the instructions for mod #2 doesn't make sense. We're trying to avoid this.
Shelley, no part of the code is "hands off," patches and improvements are welcome for all parts of the code. This, like many open-source products, is a meritocracy. CVS access is granted on account of consistent high-quality submissions of code and bug fixes. You can always contact me directly with patches and/or suggestions.
Randy, our goal isn't to limit the number of people contributing, quite the opposite. Patches and such are sent in daily, and if accepted I commit them with a message crediting whoever sent them in.
Shelley, I hope your concerns are addressed by now. Anyone who wants to contribute to the development is free to send in patches. Anyone who wants to become involved with the documentation project is free to join the documentation mailing list. And of course the wiki is open to everyone.
Excellent discussion all around.
BTW, Ryan (rboren) became a "developer" through exactly the process he described.
but allusion, opera was not even in the list of softwares u install on ur blog. :O)
and dont tell me u never used a IE hack for any of wp related webpages :P
This topic has been closed to new replies.