PDA

View Full Version : Suggestions for optimal Modification Management


The Geek
15 May 2006, 10:37
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
15 May 2006, 11:08
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
15 May 2006, 11:23
Thanks Marco,

I would rename it if I could think of a better title :D (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
15 May 2006, 11:35
Any good now?

creedmaniac
15 May 2006, 12:05
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
15 May 2006, 12:36
Much better Marco :D

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

Revan
15 May 2006, 13:04
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
15 May 2006, 18:20
Anything to get multiple contributers working on the project is a serious step forward.
How plausible is something like that?

Freesteyelz
16 May 2006, 01:42
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
16 May 2006, 07:38
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.

The Geek
16 May 2006, 09:01
I think the privacy issue is a weak one, what kind of privacy data are you divulging because you downloaded a modification?
If someone is really paranoid about an author seeing they downloaded 'separate sticky threads from normal threads' then I think they should not bother downloading it.

However, thats just my opinion (and you know what they say about those!).

To me, these (and other) suggestions can easily be broken into multiple projects and then married together.

As far as I can see at this stage, we have:

1- A mini bug tracker (related to release by a projectid)
2- A mini rating/rep system (related to project and user)
3- A download/upload system with browseable history (related by projectid)
4- A project manager

If we can settle on core components of the system, then maybe we can start to organize teams to work on them?

COBRAws
16 May 2006, 15:38
Great suggestions TheGeek! yesterday during all those discussions about hackers leaving, not getting enough recognition and so on, I thought about a way of tracking installations. Anyway its not the greatest, but could be taked into consideration if hacks weren't just a single xml file.

For instance, you get a 2 step install screen here @ vb.org. The first one showing all the details about the hack, what it does, what vb versions support it, screenshots and how you can benefit from it.

The second window will allow the users to download the plugin, code modification, skin, whatever it is. And when THAT second screen/window is accesed and, I dont know, but maybe 10 seconds pass, the install button is automatically clicked/add 1+ to the install count.


What I dont like, is when you install a hack in a board, it automatically installs here in vb.org. Because most of us work with a lot of boards, maybe giving "installation" support, or helping other people around. And then when I come here, we have dozens of hacks we really dont care ;)

Appart from this, im not really sure if when we un-install some plugin/product, happens the other way around. Does it un-install also here at vb.org? :S If this is so, its really bad.


Just my 2cents. For coders to get their installation count more accurate.

Thanks!


ps. TheGeek u're never on a bad mood! Even your hack installers are full of joy and fun! =D keep it up

Marco van Herwaarden
16 May 2006, 16:08
Thank you for voicing your opinion COBRAws.

But let's please use this thread to discuss future improvements to vBulletin.org, and not to have here another discussion about the Auto-install issue. Let's keep this thread clean and only do future suggestions.

COBRAws
16 May 2006, 16:13
Sorry MarcoH64

The Geek
16 May 2006, 16:39
Is anyone truly bothered if the author has the ability to see who downloaded, what version and when?

I envision this being different than an install button.

To me, an install button is a form of:
1- Users being able to quickly see what modifications they have installed.
2- Users being able to keep notified of what modifications are updated.
3- Supporting the author.

I guess I just don't buy that there is any privacy issue here. If you downloaded it, why does it need to be kept a secret from the author?

Freesteyelz
16 May 2006, 23:53
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.

I can't say that I fully agree but I respect the reasons. Thanks, MarcoH64, for addressing my questions. :)

uae
17 May 2006, 09:15
Pretty good job Sam...
I myself like the idea of a team working together, where coders check one another's code since we're releasing our hacks for the sake of sharing, and for free!
Everyone is going to benifit from this, especially coders.
I don't mind getting an adivce (supports) from others, getting to know all the (how, where, why and when) needs taking my mods to the next level.

Boofo
17 May 2006, 09:36
Is anyone truly bothered if the author has the ability to see who downloaded, what version and when?

I envision this being different than an install button.

To me, an install button is a form of:
1- Users being able to quickly see what modifications they have installed.
2- Users being able to keep notified of what modifications are updated.
3- Supporting the author.

I guess I just don't buy that there is any privacy issue here. If you downloaded it, why does it need to be kept a secret from the author?

Like you, I personally, don't see a problem with it, but there could be if a member here was ever contacted by an author, for whatever reason, and that member felt like their privacy was invaded. Not saying it would ever happen, but an author could use something like that as a mailing list for any future hacks (commercial or otherwise) that he/she does.

Revan
17 May 2006, 09:58
Like you, I personally, don't see a problem with it, but there could be if a member here was ever contacted by an author, for whatever reason, and that member felt like their privacy was invaded. Not saying it would ever happen, but an author could use something like that as a mailing list for any future hacks (commercial or otherwise) that he/she does.I understand what you're saying and I know that isn't the only reason (if it's even a reason) as to why it's kept private for all those not posting in the thread, but why not impose a rule where the coder that employed such tactics would be punished, maybe even banned if the activity keeps up?
I mean, it wouldn't be too hard to figure out who did it, since the product they would be advertising would be traceable to said coder =P

I just hope that if it is made public, it won't scare users away from clicking the install button for whatever paranoid reason. It's hard enough to get people to click install as it is.

Boofo
17 May 2006, 10:08
Point taken AND noted. ;)

When it comes to privacy, it gets to be a very controversial issue. It can be something totally innocent, and yet all it takes is one person to screw it up. Sure, you could take action against anyone who did it, but by then the damage would have already been done. And all the person has to do is let everyone else know what happened, and then you have a privacy scare on your hands. ;)

Marco van Herwaarden
17 May 2006, 10:57
From the "Send Update" page:
Send a mail to all Users which have installed this Hack
Update info:

This is ONLY to be used to send hack update infos. No advertising, spam or other problematic text is allowed.

And still we get at regular intervals complaints from members that the update mails are being used to advertise commercial products.

Only posting this to show that it is not only a hypothetical problem.

Revan
17 May 2006, 10:57
Personally I don't see a need for knowing who clicked. I'd take a high number of install clicks over seeing who actually did it any day.
It could be useful for some hacks that has a specific ToS tho, like Marco's PM-something whatever hack that stated that you had to leave the "admins can read your pms" or whatnot notice in there. They would benefit from being able to monitor boards using the hack.

Marco van Herwaarden
17 May 2006, 11:02
Good example of where it could be usefull, but i guess that it wouldn't be the case for 95% of the hacks. (and though usefull for the author, i doubt my (as a coder) interest would weight enough to change this.

The Geek
17 May 2006, 12:05
The privacy argument is kind of moot when you consider that anyone that did click install and posted in the thread will easily be identified by the author - thus allowing them to spam, exploit, or whatever.
So to protect yourself it seems like we should never click install and never don't post in the thread!

My final point being - if you need to keep your download a secret: don't download it! There are always going to be tripes that abuse things. However you can't line the world in bubble wrap just in case someone falls down (though a world lined in bubble wrap would be a hoot).
Ban the buggers that don't follow the rules. If it's a blatant spam using the notification email system - ban them for 2 weeks (or whatever).

That is how you ultimately prevent people from taking the piss.

Marco van Herwaarden
17 May 2006, 12:53
Ban the buggers that don't follow the rules. If it's a blatant spam using the notification email system - ban them for 2 weeks (or whatever).
We have currently one under investigation. If we find that the report by a member is correct, and the update has been used for advertising only, we will ban that author for 2 weeks and redirect any complaints to you. Ok? ;)

Boofo
17 May 2006, 12:58
The privacy argument is kind of moot when you consider that anyone that did click install and posted in the thread will easily be identified by the author - thus allowing them to spam, exploit, or whatever.
So to protect yourself it seems like we should never click install and never don't post in the thread!

But what about those members that click install and don't post in the thread? Like you said, posting members the author can see anyway, but there are a lot of members who download hacks and never post in the thread. ;)

The Geek
17 May 2006, 13:44
Hence the reason for my double negative statement:

So to protect yourself it seems like we should never click install and never don't post in the thread!


While a lesson in shoddy grammar, the point still remains. If the primary purpose for hiding a downloaders name was to protect them from an impromptu coder dropping by your house with a bag full of Amway product, then why not extend the courtesy of protecting those that actually posted? Hence the reason its a moot (I am oddly attracted to that word) argument.

47667
"Protect or Do not protect. There is no try."

Its actually absurd anyway. If you are so freaked by it - don't download it. Don't put rules in place for 'what may just happen'. Heck, you shouldn't let anyone even upload anything to the site. A modification you downloaded here could possible make 1-900 number telephone calls on your behalf when you're not looking! THE HORROR!

Anyway. I'm really making a mess out of my point now. So ill meander along. I really could give a rats walnut about it - I just have a bizarre habit of standing up against something if I think its odd, freaky or unfair.

@Marco - I'd be happy to have them here (http://www.newrafael.com/sites/misternicehands/pmf.swf).

Thanks!

Bhuwan
17 May 2006, 13:47
bug tracker!

uae
17 May 2006, 15:46
bug tracker!
A bugtracker is a ticket tracking system that is designed especially to manage problems (software bugs) with computer programs.

http://en.wikipedia.org/wiki/Bug_Tracker

A mini bugtracker for every mod release.

Paul M
17 May 2006, 19:50
I have (a number of times) asked to be able to see who installed a hack, and also when - as this indicates what version they downlaoded - very important for support purposes.

Like anything else - if you make it known that the author of the hack can view a list of who installed it, 99% of people are just not going to care (I'd bet a fair few already think you can ;)) - those that do care can click uninstall.

The spaming of users from a list of names is a non starter - the only way you could do that is via PM, five at a time - that would be more effort than most people would be willing to put in, and not hard to spot.

hambil
17 May 2006, 19:57
I repost this here, since I think it belongs:

I think we should hook into the hack database like Windows does for updates. A single product could be written that acts a lot like Windows Automatic Update. The user could select "automatically update" or just get notifications when they log into their board, and click on the manual update button.

The product would check what other products and plugins they have installed, and report back to the hack database to check for updates and manage install counts.

The benifit to the user would be automatic security updates and hack updates. The benifit to the coder would be an accurate install count.

It could work over https and be as secure as we can make it. Only people who install the product would be reporting to the hack database, so it's completely opt-in.

Gaskell
17 May 2006, 20:16
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 Sounds a good idea. Got all this unused potential here going to waste. The coders here code vB mods because they like the software. Why not let them put something back into it, at least on a small scale? Not a coder myself, but I would definately be up for some beta testing if this were to happen some time in the future.

The above points have probably already been said somewhere in a similar post on here by someone else

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. Shouldnt be too much hassle, even just an advanced search based on the tick-boxes on modification releases set as a link on Forums Index (for one approach) :)

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. Another good suggestion. Would be canny, especially in "hot" releases where theres odd bugs in the middle of loads of "cool hack!" posts. Easier for coders to keep track of things they need to sort and to keep users up to date without spending ages looking for relevent posts :)

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. At-a-glance feedback for coders and easier for users to see what mods people are happy with? Sounds a good-'un :)

stonyarc
17 May 2006, 21:16
I also think that if we implement bugtracker/project management we should also make it multiuser.

That way some users can go coop on mods.

I had to put some of my projects on hold just because I don't have the time. If I could work together with another coder/designer/.... that would save time for a lot of coders/designers/members/... and maybe create some additional inspiration for the people working on the project.

Team based mod db (a team can be 1 person too).

Also I think it's vital we have some documentation standards set and included in the mod db. I noticed that since I started adding a well documented guide with all my major mods the number of "avoidable" support questions has dropped a lot.

Freesteyelz
18 May 2006, 01:05
If someone who've installed a hack and clicked "Install" unchecks "Receive Email from Other Members" via User CP, will he/she receive an e-mail if the hack author sends out an update?

Paul M
18 May 2006, 03:16
AFAIK, Yes.

Freesteyelz
18 May 2006, 05:19
If that's the case then there is room for the privacy argument. Though, I don't see it to be an issue at all.

GamerzWorld
18 May 2006, 09:07
Apart from for bug purposes what would the purpose be of knowing what version, who and when someone download your hack? If you make a mini tracker, simply make the field with version compulsory? I dont really understand why the privacy thing is an issue, as far as im aware you can already automatically send updates, so what would really change?

creedmaniac
18 May 2006, 09:34
i'd like to see another custom field in the installed hacks section of the usercp that allows each member to type in stuff for that hack...like a notes section for themself (i would use it for noting which site has what mods on it...since i don't install all of them on all sites..but it could be used for anything)

The Geek
18 May 2006, 10:33
If that's the case then there is room for the privacy argument.

Not really. What you're saying there is:

vBulletin protects privacy through not discolosing if you downloaded a modification to the author as long as you 1- don't post in the release thread and 2- make sure you have ticked 'do not recieve email'. If you have posted in the release thread and allow members to email you through the site - you have a teeny weeny risk that someone is going to add you to their chritmas card mailing list.

Considering that you can only send 1 person at a time an email - you're in for the long haul and you should start at Easter.

You can only argue the privacy thing if it is enforced across the board (which it isnt - therefore it can't matter THAT much).

To me, being able to see a history of downloads is a help for support issues(and something I rely on at thevbgeek.com) to a degree it also protects intellectual property.

BTW: I have been tinkering with this already. However I seem to recall that there was some possible discussion about a third party app for this system.

Can we get an idea if its worth spending any time at all on it or not? If it's worth investigating, then I'd like to post some stuff in the coders forum to see if it will help get the ball rolling with some other coders.

Thanks!

Freesteyelz
19 May 2006, 03:38
O. I didn't know I meant that. LOL.