Suggestions for optimal Modification Management

[The Geek]

A lot of great positive suggestions started coming out of the great coder debates of '06 but they are getting buried faster than the great avalanche of '83.

Therefore I am taking the liberty of starting a clean thread for the discussion of the modification database ONLY. It is my hope that the other suggestions may follow a similar vein (starting a fresh, dedicated thread), that we can leave debate over how un-l33t we f33l at the door and that every household will have vBulletin on the kitchen table.

end preamble.

Development

Harness some of the coders here to create the system. To do this project right, it will take ages for 1 person to do. Furthermore you wont get a fraction of the features implemented that coders and users want which will result in people whinging about it.
Sure there are security concerns - however a team working together can check one another's code and the whole thing doesn't have to go live until it gets an OK by vb staff

Filter system.

The current flow at .org is confusing. Modifications are grouped into a few odd categories (plug ins, extensions, etc...). I see the thought behind the concept - however users want to be able to group based on functionality, not on whether they need ftp access (remember that vB needs ftp access so at some point they had to use it!).
It makes sense to be able to filter a search (or just a regular listing) of modifications that meet a particular criteria. Some suggestions off the top of my head are:

• Requires vB file changes
• Requires vB template changes
• Contains additional files
• Contains additional templates
• Known to work with vB version x
• Has more than x Installs
• Adds functionality in x Areas (sounds odd, but kind of how the categories were group before: forumdisplay changes, user profile stuff, showthread stuff, etc...)

There are loads more, and certainly you wouldn't need them all, however it could prove VERY useful to coders AND users.

Track downloads

As an author, you should automatically track that which users downloaded, the version they downloaded and the date it was downloaded.
Sure, many may download just to tinker or to check out some of the code, however they still downloaded it! Furthermore it could make it easier to determine problems for users (The problem is that you are using version xyz. Try the latest files). This would get around the 'install' dilemma.
Allow users to 'uninstall' - however make a mandatory field that requires them to state the reason: 'I just wanted to check it out', 'I had problems with it', 'it dint do wot I thought', 'The geek is a butt wad', etc...).
That would allow users to browse reasons why people choose not to use it anymore (maybe even allowing the coder to comment just in case 'the guy thought it sucked because he didn't even freaking upload it!).
Sure, you're going to get into tripe debates - but overall it would be a useful system for people to see if modifications are hot and if not, why not? (look - I'm just freaking suggesting it!!!)

Mini Bug tracker

I really do not feel that this would be overly difficult to implement, however it would clean things up dramatically. Allow people that have downloaded the modification to post in a bug tracker associated to that release.
This gives coders a one stop place to find, control and track bugs and the users a one stop place to see what issues are outstanding.
Leave discussion forums for troubleshooting and general discussion.

Feature request box

Have a 'suggest a feature' box where users can submit a suggestion for implementation and allow the coder to respond. It can be difficult to track down all feature requests in a thread for implementation. Feature requests are a plus for the coder and the user. Feature requests also help users identify what features are lacking in a release (maybe one they are looking for!)
OK, a feature request box may be lame. I just came up with it and thought there could be some merit in it.

The coder/designer/project smilie system.

Allow users that downloaded (and hadn't uninstalled the system) to give the coder/project on its merits (kind of like a positive only rep system):

• Functionality
• Ease of use
• Features
• Support

Let the user give them a smilie if they feel it warrants it. For instance, the functionality was good so they get a smiley face there, but support was only mediocre so they get nothing there. No rating, no frowny smiles, only big grins (i.e. this project has over 50 functionality smilies). It could be a cool incentive system. Then again, I could have had too much crack with my Cheerios this morning. Regardless, look at some kind of a rating system.

I've bantered on long enough for the first post and I know there are a lot of other great ideas floating about so I'll jump off my suggestion box and give another geezer a minute or two while I work out my writing cramp.

[Marco van Herwaarden]

Very good idea to start a suggestion thread on each topic, i think a lotof good suggestions in other threads get burried in the number of unrelevant (for that suggestion) posts in a thread.

I would like to ask you to rename this thread (not sure if you have permission).

We are discussing improvements on how modifications are presented and all the processes around it. The so called Modification Database is just a small part of it, and is not much more then custom fields to a thread that are needed to store the information needed with Modifications and a way to search those fields.

Your post go way beyond that, which is good.

[The Geek]

Thanks Marco,

I would rename it if I could think of a better title (just not Hack DB, anything with the word Hack in it gives some people the willies!)

Please feel free to change it as you see fit (or any other staff member for that matter).

And also count me in on helping if I could. My time is tight - though its yours if it will help. I am certain there are plenty of others that would chime in as well.

[Marco van Herwaarden]

Any good now?

[creedmaniac]

I have an idea for that mini-bug tracker...(word of warning...i'm not a coder so i have no clue how hard this would be...but it seemed neat to me)

Have the mini-bug system 'multi-faceted'. Where when a user puts in a bug for that specific hack, it gets added to that individuals hack log, but also the hack author should have an area in his usercp that shows all the bugs for all his hacks, and vice-versa for the users...they have in their usercp a list of all the bugs they have submitted

[The Geek]

Much better Marco

Creed - sure. I don't think it would be hard to add the functionality as they would be standard querys.

[Revan]

Allow me to offer a solution for the security concern: SVN (/ CVS).
Not only would this not force coders to get their code validated by vBorg staff right off the bat, but it would also allow for a wider team of coders working on the same project without the fear of "double feature coding" if you get my meaning.
Also, even if you do get a malicious user who just wants to delete everything, then all youd have to do was Revert to the previous revision, and all the work is restored.

I have yet to work with SVN in a "real" team environment, but I do back my RPG Integration Hack up on SVN, which so far has worked really well. It's also a relief that if I do get offers of development help, it's simply a matter of allowing access to the repository.

At this time I don't have any suggestions for improvement, but when I get home I will review and post comments on the rest of Geek's message

[The Geek]

Anything to get multiple contributers working on the project is a serious step forward.
How plausible is something like that?

[Freesteyelz]

Nice suggestions.

With regards to Track Downloads do the authors have a way of knowing which members clicked "Install" under the current system without them having the need to post in the mod thread? If not would that be useful for the authors in the Mod Database?

[Marco van Herwaarden]

No in the current situation authors can only see if someone clicked install if they post in the thread.

It has been suggested in the past to change this, but until now it was always declined because it could invade the members pirvacy, while on the other hand it has no significant benefit for the author.