Sticky plugins in the plugin design page.

[bobbintb]

i realize there may be too many plugins to do this but i think it would be a good idea to sticky the posts that contain plugin downloads, or at least make one post with all the links and sticky that. i do realize that this essentially mimics the functionality of the wiki, but really, only to a point. most people go directly to the forum anyway, especially if they are there for support. just food for thought.

[DaleWilliams]

I agree.

It would be nice to have even a simple table that shows:

Plugin Name  | Current Plugin Version |Compatibility (unRAID 4/5/6)| Release Date  | Link to Forum post.

The Wiki might allow this...is there a better way?

[WeeboTech]

Perhaps a forum sticky that points to the Wiki.

A table can be created in both, however only the original poster or moderator can update a specific post, whereas any registered forum member can add to a Wiki page.

[jumperalex]

OK well since this is coming up now I'll mention it here vice the forum mx thread:

 

I recommend another sub, possibly called "How-To" or something where the OP is from the plug-in author / maintainer and their post / posts detail the current best-of instructions and downloads.  Ideally the first part of it might even have a template format to make it easy to find important details like version, last update, system supported, link to discussion thread, etc.  Same goes for the subject title, there should even be rules/guidlines about what should be in the subject to make searching easy.

 

And that is it.  The thread is locked and all support requests, update discussion etc goes in separate threads started by the person asking a question.

 

The benefit to such a syste, as I ahve seem on many automotive / motorcycle / android sites is that it makes it very easy to search and find simple concise info about How-To do something.  It also declutters that section from all the discussions.  If the project gets abandoned and someone else picks it up, all they have to do is copy the How-To OP into a new thread, and at some point the mods shuold modify the now abandoned thread's subject with  [DEPRECATED] or [ABONDOND] and then add a link in the body to the new thread.

 

TLTD; dissociate active functional application/plug-in/custimization How-To's from their support discussions and enforce title standardization.

[DaleWilliams]

Excellent points, Jumperalex.

I like having a 'definitive' instructions board.

How does the 'lock' work with updates? Does the plugin author send in his definitive contributions to a moderator? Or can the original poster (plug-in author) continue to edit his original post without moderator help?

[jumperalex]

PS: I know the wiki seems like a great idea but honestly no one searches it.  I base my assessment by how many people ask questions that are answered via the wiki (myself included sometimes).  I'm talking specificaly about the non-fficial stuff.  Official LimeTech info belongs in a well organized Wiki. But all the user generated stuff is debatable IMHO.

 

That said, if the wiki is to be the repository of "known good and up to date" info, then there needs to be a direct link at the top of this forum (read: not in the rotating news section) and it needs some serious reorganizaion.  I'd recommend its organization mirror the Forums and each forum sub- has a link (or links) at the top to its corresponding wiki pages. So for example, there should be links at the top of the Announcements thread pointing directly to the 64 Bit Compatibility page.  And once Tom creates a dedicated v6 section, those wiki links would migrate there as appropriate. There should be a direct link from the Virtualization section to a Wiki virtuatlization page.  etc.  And these should be big promimant obvious links to catch the eye of the users searching for information.

[jumperalex]

Excellent points, Jumperalex.

I like having a 'definitive' instructions board.

How does the 'lock' work with updates? Does the plugin author send in his definitive contributions to a moderator? Or can the original poster (plug-in author) continue to edit his original post without moderator help?

 

There should be no problem locking a thead to new posts but allowing the OP to make updates to their posts.  At least I know the car boards I frequent can do it.  But if not, then the OP can ask the mods to unlock a thread for update.  Updates shouldn't be that frequent since a thread won't even exist until the "thing" in question has reached a certain level of maturity (read: may require mods to approve even posting to the How-To section) and updates shouldn't be occuring until it is suitibly stable.  So no, "hey i think this might fix the problem" updates.  Those belong in the support threads.  Once a fix or update is deemed stable, then it gets updated in the How-To thread.

 

I know it sounds like I'm adding work to the mods, and yes I am, but it shuoldn't be TOO much (especially if the forum software can support) because the ideal is that these "special" threads are posted and left alone except when there is a damn good reason for updating them.  All the other support threads behave just like now.

[kizer]

Something like this does exist in This forum software as a Mod. I used it for a while on my website.

 

It could be added and then stickied at the top of the Particular Forum section as an index.

[nicinabox]

You're bumping up on yet another shortcoming with the current plugin system. Forum's are a Really Bad Way to manage code and support requests. It doesn't scale at all. It creates tons of extra work for the moderators and extra work for developers.

 

Authors should...

 

* version and tag their code

* use a proper tool for support requests

* write a proper readme

* perhaps maintain a project specific wiki if necessary

 

The goal should be that plugins become autonomous, self-maintained parts that work together and don't require TONS of overhead.

 

Github is a really really fantastic tool that would help ENORMOUSLY with what people are doing. Influencer did a really good job of this on his UNplugged repo (issues, wiki). This is the right way to go about it.