vb.org Archive

vb.org Archive (https://vborg.vbsupport.ru/index.php)
-   vBulletin.org Site Feedback (https://vborg.vbsupport.ru/forumdisplay.php?f=7)
-   -   Duplicate Mods (https://vborg.vbsupport.ru/showthread.php?t=194953)

Lizard King 10-29-2008 07:13 PM

Duplicate Mods
 
As there is an active ranking system on vbulletin.org for coders and designers , why dont you guys allow duplicate mods.

Instead of duplicate ods , it can be solved by choosing multiple vbulletin versions. Currently people release same mod with no single change on different sections on board which makes the ranking system in accurate.

Guest190829 10-29-2008 07:58 PM

I think it good suggestion, right now forum based separation is flawed in my opinion. Perhaps we can incorporate threads tags for this...it's really what tagging is all about when basic ontological separation is too limited.

nexialys 10-29-2008 08:12 PM

Hey Danny, that would mean we switch the site to 3.7 at least, so maybe an analysis IN PUBLIC of how the coders see the situation and how WE can bring solutions for the older stuff too ???

because sorry for my arrogance, but all the times, these decisions are debated in private, discussed for X minutes, and abandonned, cached or stored for future references... and nothing is never done.

Brad 10-29-2008 08:22 PM

Quote:

Originally Posted by Lizard King (Post 1655549)
As there is an active ranking system on vbulletin.org for coders and designers , why dont you guys allow duplicate mods.

Instead of duplicate ods , it can be solved by choosing multiple vbulletin versions. Currently people release same mod with no single change on different sections on board which makes the ranking system in accurate.

While a lot of modifications don't require it; I've been ranting for years about the fact that we need "project webpages" like they have on sourceforge. For anyone that isn't up to speed with what I'm talking about see; http://sourceforge.net/projects/sierra-php/ for an example.

Some key things I've been wanting to see for awhile;

- Ability to upload/host multiple copies of the software. I know this is possible with the current attachment system but I'd like to see something more user friendly (like having them listed by version number).

- Sub-forums for modifications. The main ones we need; Support, Bug reports, General Development.

- Ability to browse a modifications source code before downloading it. Hosting the modifications in a repo system. (I'll get to this in a second).

- Ability to have an "FAQ" on our modification's page.

- A way to update users outside of sending e-mails and editing threads. We need a way to post news about our modifications.

Going back to storing modifications in a repo; It'd be neat if I could download and install modifications directly from my admincp (*hint*).

Guest190829 10-29-2008 08:24 PM

Quote:

Originally Posted by nexialys (Post 1655594)
Hey Danny, that would mean we switch the site to 3.7 at least, so maybe an analysis IN PUBLIC of how the coders see the situation and how WE can bring solutions for the older stuff too ???

because sorry for my arrogance, but all the times, these decisions are debated in private, discussed for X minutes, and abandonned, cached or stored for future references... and nothing is never done.

In any administration (and I'm not just talking about online communities here) most of the discussion and planning is done privately.

Have you ever heard of the old saying "too many cooks in the kitchen?" I have, and I've also experienced it far too many times...talk about things never getting done.

And your arrogance aside, you have no idea what goes behind the scenes of vBulletin.org so it's really not accurate or fair to say how many "minutes" these topics are discussed.

As a user, you're suggestions are invaluable. I don't know how many times I've said that no suggestions are ignored. Leave the administration aspects of this site to the staff. Trust me, it's for the better.

And I don't want this turning into another needless argument or debate, so please just don't even bother. Please, only post directly about the suggestion topic.

Lizard King 10-29-2008 09:20 PM

Quote:

Originally Posted by Brad (Post 1655598)
While a lot of modifications don't require it; I've been ranting for years about the fact that we need "project webpages" like they have on sourceforge. For anyone that isn't up to speed with what I'm talking about see; http://sourceforge.net/projects/sierra-php/ for an example.

Some key things I've been wanting to see for awhile;

- Ability to upload/host multiple copies of the software. I know this is possible with the current attachment system but I'd like to see something more user friendly (like having them listed by version number).

- Sub-forums for modifications. The main ones we need; Support, Bug reports, General Development.

- Ability to browse a modifications source code before downloading it. Hosting the modifications in a repo system. (I'll get to this in a second).

- Ability to have an "FAQ" on our modification's page.

- A way to update users outside of sending e-mails and editing threads. We need a way to post news about our modifications.

Going back to storing modifications in a repo; It'd be neat if I could download and install modifications directly from my admincp (*hint*).

I agree that modification pages can be improved. Supplying each modification a page of its own is a good idea but i honestly dont think it is possible to handle this while allowing comments and bug reports on same place. That why it may not be possible.

My main reason for suggesting this is directly related to vBulletin.org's Coder ranking system. https://vborg.vbsupport.ru/vborg_mis...eleases&type=1 follow this link and you'll see what i mean. nearly 90% of this releases are duplicate of even 3.6 version nearly. This way coders double or triple their release and install number.

I personally donot release anything at vb.org for various reasons but people depend on coder rankings for paid modifications which may mix their mind up.

Danny's tag solution may work or custom fields can be used such as coders can choose which versions the mod will work with.

This is also a problem on coders side since he needs to support the product in two different threads.

Paul M 10-30-2008 12:40 AM

While it is true that releasing the same mod in two areas (like 3.6 and 3.7) will affect the coders ranking, it wont actually have as big an effect as some think - as each area has a preset weighting, so mods in the 3.6 area do not count as much as mods in the 3.7 area. The older the version, the less weight it has.

If the site was starting from scratch then we wouldnt have seperate areas, there would be some sort of version system in the release thread to show which vb versions it was valid for. However, doing this now would cause a huge headache and potentially tons of work trying to get all existing releases to use a new system. Besides which there are often minor differences between releases anyway.

Maybe when vb 4.0 comes out a new system may be looked at, since its likely that 99% of existing mods will need to be updated and re-released at that point, I think any change before then is highly unlikely.

nexialys 10-30-2008 01:26 AM

/me have to applause Paul M for this answer...

cheers !

Dean C 10-30-2008 08:20 AM

Quote:

Originally Posted by Paul M (Post 1655702)
While it is true that releasing the same mod in two areas (like 3.6 and 3.7) will affect the coders ranking, it wont actually have as big an effect as some think - as each area has a preset weighting, so mods in the 3.6 area do not count as much as mods in the 3.7 area. The older the version, the less weight it has.

If the site was starting from scratch then we wouldnt have seperate areas, there would be some sort of version system in the release thread to show which vb versions it was valid for. However, doing this now would cause a huge headache and potentially tons of work trying to get all existing releases to use a new system. Besides which there are often minor differences between releases anyway.

Maybe when vb 4.0 comes out a new system may be looked at, since its likely that 99% of existing mods will need to be updated and re-released at that point, I think any change before then is highly unlikely.

I hope those weights don't change over time. I released a lot here a long time ago, and whilst those hacks don't apply to many boards these days, they did at the time.

Marco van Herwaarden 10-30-2008 08:49 AM

Yes they do change over time with new vB versions released.


All times are GMT. The time now is 10:29 PM.

Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2025, vBulletin Solutions Inc.

X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.01092 seconds
  • Memory Usage 1,752KB
  • Queries Executed 10 (?)
More Information
Template Usage:
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (4)bbcode_quote_printable
  • (1)footer
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (6)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (2)pagenav_pagelink
  • (1)post_thanks_navbar_search
  • (1)printthread
  • (10)printthreadbit
  • (1)spacer_close
  • (1)spacer_open 

Phrase Groups Available:
  • global
  • postbit
  • showthread
Included Files:
  • ./printthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/class_bbcode_alt.php
  • ./includes/class_bbcode.php
  • ./includes/functions_bigthree.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • printthread_start
  • pagenav_page
  • pagenav_complete
  • bbcode_fetch_tags
  • bbcode_create
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • printthread_post
  • printthread_complete