The MOD team always gets a lot of questions, feedback and more from MOD authors. This is mostly after a persons MOD was denied for a certain reason, we change something, or just about one of the policies we have.
We get a lot of questions from them if we do anything with the feedback, or if we actually listen to it, I want to explain here how we handle this kind of feedback.
The things we receive the most feedback on is, as I said already, validation, policies, and also things like MODX, MOD documentations etc.
Mostly when we get feedback from users the MOD team member that reads the feedback replies and thinks about it or will discuss it on IRC with fellow MOD Team members. If the feedback is new he makes a topic in a private MOD Team forum for further discussion. If the feedback is something we’ve heard before it may not make it to discussion because it is something that we won’t be changing. If we get the same complaint many times we will bring it back up for discussion.
After its discussed and a decision is made we start implementing the change or do nothing depending on the decision. In a lot cases, implementing the change can take some time because we need to test changes, update the website, write documentation and anything else we need to do to prepare for it.
The last stage before implementing the change is the testing stage. We always need to make sure its working correctly :). After that we announce it or just make it available at the website. Things like a small change in the MODDB get to the live site a lot faster compared to changes in MODX.
A few good examples of the things we do with the feedback are here below. These examples are mostly from some time ago, but also some more recent changes.
MODx 1.2.0
The MOD team has received a lot of feedback in the MOD Authors forum about the current revision of MODX. That revision had several problems and was complex. After getting feedback from the MOD authors and the normal users we made a list of what things we want to change.
The result of this was the release of a new MODX version. Within this release the packaging was updated to include a new, less strict policy. This new policy allowed authors more freedom on how they package their MODs. Also the version tags were changed because a lot of MOD authors didn’t understand how to use the old version tags.
Beside a lot of good things MODX 1.2.0 also did give several problems. Before the release of MODX 1.2.0 we had a tool to automatically check MODs for basic problems. With the MODX update this tool no longer worked and we were required to write a new one (The new tool is currently in testing). This slowed down validating MODs due tohaving to manually check for these basic problems.
A new special page was made to describe on how to update MODs to MODX 1.2.0 because many MODs were getting denied for not updating to MODX 1.2.0 correctly.
A lot of changes to the XSL that were written by MOD authors have been added to the official release and will continue to be added.
MOD packaging Updates
The MOD packaging rules have been updated several times after receiving feedback from users. One of the first changes we made was some small changes to the policy to include things like how languages and and templates are packed.
The second change was larger. This was a complete new policy coupled with the release of MODX 1.2.0. This policy was based on simplicity and requests from authors. The policy is not as strict as it use to be and allows authors to be more flexible.
We are currently looking in to doing another new update to the policy because there is a problem with Firefox 3 and XSL style sheets. In the current policy we only allow one XSL but because of a Firefox security policy this will not work in Firefox 3. We currently do not know how this problem will be fixed.
MOD Database
The MODDB is a special case. Most feedback we get on the MODDB is about the validation itself and how long it takes. We have received some good feedback on some parts on the MODDB and have added the requests to the DB. We are always looking for more feedback on it so we can improve it. We gotten some requests lately and these will probably be added later this month.
Insta-deny
Insta-deny is a rule that we can deny a MOD within 24 hours after submission. This is done after running our validation tool. We got some comments from users about the “repack by minor mistakes” check box, and we are currently discussing on how we are going to handle this.
Repack policy
As I already said above, for a lot MOD authors it’s not clear when we will repack a MOD. We are currently discussing internally what things we will repack and will publish a document later on what kind of things we repack.
Validation
We receive feedback on validation the most. In most cases, a MOD is denied on its first couple submissions. This can be because different people are validating it each time and finding different problems or the same person is finding things he missed before. When this happens we include a comment about reading the documentation and such.
The biggest complaint is that it takes too long. We try to validate a MOD within 2 weeks, but it can take up to one month. Even one month is not always possible because validating a MOD takes a lot of time (For who is visiting Londonvasion, I will be giving a presentation about what MOD validation really is). There are always a lot of MODs in our queue, and validating a MOD can takes several hours.
We are still looking for ways to make MODs validating faster, things like insta-deny and repack are part of that.
If you have any feedback, questions or just good ideas on how make the MOD section better, post a comment here, reply to the topic in MOD Writers Discussion (There are some topics about things like MODX and our policies) or create a new topic in the MOD Writers Discussion forum.
Thanks for the explaination Paul!