General developer forum

I think "an authoritative interface style reference" is a great idea and much needed. Without one, it is very difficult for developers of new modules to create things that meet standards without having to guess and poke around for code everywhere, and therefore it would be up to Martin and his programming team to rework contributed modules to meet standards. Having an easy to follow guide would ease work on both ends.

And more heads put together on making such decisions is always good. But to avoid getting bogged down by people splitting hairs over whether to right align page headers or center them, there would need to be not only discussion, but a decision making procedure in place to actually come up with standards.

When I was editing a web site, I had to make a lot of standardization decisions, but when they were major issues I frequently discussed them with my colleagues before making them because they were the ones who would have to work with them and if we couldn't come to a consensus by discussion, we would simply vote, with the majority view prevailing. This meant sometimes I had to implement things I personally didn't agree with, but the majority liked it. Also, there are going to be nitpicky details that most people won't care to be involved with (I can tell you none of my colleagues would have been interested in the weeks long task I had of specifying various parentheses, colons etc. between strung together database fields), so you would need a leader who would be able to make these decisions when everyone else was bored to death with the details.

PS-Martin, standardization isn't something people turn to out of boredom...it's actually fun, at least in my opinion. On the one hand, it requires attention to detail, but on the other hand it requires a very broad overview of everything. You really get a comprehensive and thorough view of anything you have to standardize, which no one else working on bits and chunks of the whole has the opportunity to do.
 
Now, if I was really bored, I might take up something like coding...
 

> I tend to put feature requests in the appropriate forum and then if there is support I try and raise it in the bug tracker. I then post the forum post in the bug tracker and then post a reply in the forum with the bug number.

Yes, that's great, that is the best way currently for the people who are able to actually do something about it to see the ideas and absorb it into their thinking. You're someone who has been making an effort to actually help developers recently, thank you.

It's important to keep in mind with all this stuff that just because one person or even a few people have an interface idea it doesn't mean it will magically happen. Coming up with ideas for improvement is easy (the tracker is full of them, and I have at least five more a day) and many of them are quite obvious once you use Moodle day to day.

It's much harder to roll out a coherent package with a growth path, and there are many complex dependencies (technical, organisational, social, political, philosophical, financial) which are unseen to users. Amazing stuff goes on for developers at different levels which hopefully I will be able to describe in the final chapter of my thesis when I get back to it sometime in August.

The interface is the most important thing to keep in mind because to most users what they see *is* Moodle. It's so important there are dozens of forums for it in this course (purposefully named Using Moodle) covering every aspect. It's crystal-clear to me that WP's bandwagon or a feature request forum would only duplicate what we have already and make it even harder for developers to actually implement ideas (yes, by writing code).

In defense of the bug tracker, it is designed so as to make sure things don't get lost. If they are in there, they aren't lost, but you can't always expect them to be dealt with immediately.

I've been using the bug tracker myself since perhaps September and while some of my bugs have been addressed immediately, others have taken time, and there still are others outstanding.

I'm sure there are a lot of factors that go into deciding which bugs get addressed first and that they are all valid. We all know how busy Martin is and I have noticed that bugs that get assigned to him generally take longer (he's got about half closed and half open bugs), but that is OK with me. Specific modules that have a person solely responsible for that module tend to get their bugs addressed much faster. And who knows, you might find your bugs addressed faster than you even see as necessary. I recently submitted one as lowest priority and the programmers were all over it immediately. And I get the sense things are being read as they come in, even if they are not acted upon immediately. If it is not a bug after all, Martin is more likely to tell you that right away, if it is truly a bug, then it will get fixed fairly fast, much faster than he is going to be able to implement a new feature request. And that is the way it should be.