Survey: Plugin Library

[Brian]

Hi there!

In preparation for changes to the plugin library following the release of ProBoards Version 6 I'd like to ask some questions regarding the quality of submissions to the library. Note that these questions revolve around the acceptance of plugins to the library, not the appearance or functionality of the library itself. Anyone who has ever used a plugin from the library (even just one!) is more than free to answer any of the questions at the end of this post.

Currently, any plugin that gets submitted to the library is either accepted or rejected based on whether or not it achieves the following goals:

• Adds new functionality to the forum and/or automates a layout change that would otherwise require a substantial amount of time and effort to achieve
• Contains valid, error-free code as far as testing can confirm
• Includes a relevant name and description
• Includes library images that are relevant to the plugin and meet the image resolution restriction stated in the admin area
• Sanitizes key data (if the plugin uses keys)
• Abides by the Developer Guidelines

Since these aren't formally stated before the submission process many plugins of varying degrees of quality get submitted to the library. Rejections are often given due to lack of a plugin description or images showcasing at least some aspect of the plugin, or even if a plugin is too simple (example: adding a static container with no extra functionality which could be handled in headers/footers/templates). In the interest of improving the quality of future submissions I'd like to enforce quality standards based on your input.

• What goals do you believe a plugin should achieve to be eligible for the plugin library?
• What should the images included alongside a plugin's library entry depict?
• What do you believe a plugin's description should include?
• Do you have any other suggestions?

[Retread]

• What goals do you believe a plugin should achieve to be eligible for the plugin library?
  The goals stated in the OP of this thread seem appropriate to me.
• What should the images included alongside a plugin's library entry depict?
  I think that very much depends on the particular plugin. Some plugins almost don't need an image to make it clear what the plugin does (and doesn't do). Others will benefit greatly from several images.
• What do you believe a plugin's description should include?
  Again, this depends on the particular plugin. But the basics are: What does this plugin accomplish and what are its limitations.
• Do you have any other suggestions?
  Yes. (see below)

---

I'd like a help thread for each plugin to be mandatory. The current way doesn't really support that without the potential for clutter. If a Help Thread is created in the Plugin Library board before the plugin is submitted for approval, there will be a useless thread in the event the plugin is rejected.

To work around this, perhaps a private sub-board could be nested beneath the Plugin Library board? Anyone preparing a plugin for submission could create their help thread in the sub-board, then use the link to that thread within their plugin. Upon approval, the Plugin would appear in the ProBoards Library and the Help Thread would be moved from the sub-board to the Plugin Library board.

Does that sound reasonable?

---

Since plugins themselves can be an important learning opportunity, making it obvious whether or not a plugin is editable would be a very desirable addition. When the radio button for Editable (Yes) is ticked, could this information be displayed in the ProBoards Library listing?  Perhaps in a similar way to how Key Usage is displayed?

[Kami]

• What goals do you believe a plugin should achieve to be eligible for the plugin library?

In addition to what is already being checked for, plugins should also contain usage instructions within the plugin itself as well as have clear and concise element and file names (instead of var = "alksjfkd" or image01.png). Many is a time I have installed a plugin for the only information to be the plugin name and a field with no indication of how the plugin should work, which not only makes it difficult for less advanced users but also means that there's less clarity to the plugin after time has passed and the download page description is long forgotten.

Users should not be obligated to leave their forums to understand how a plugin works, unless they need 1:1 help from Support.

• What should the images included alongside a plugin's library entry depict?

Images should include a shot of the editable portions of the UI, and a shot of the plugin "in action" -- for complex plugins with multiple parts, this "in action" shot should depict the plugin being utilised to its fullest extent.

• What do you believe a plugin's description should include?

A plugin description should include the # of keys used, the goal and purpose of the plugin, its limitations — if there isn't a separate section for (mandatory) usage instructions, then usage instructions as well.

• Do you have any other suggestions?

I echo Retread 's suggestion of making a link to a help thread mandatory and support his suggestion on utilising a private board to manage unapproved plugins' help threads.

[Brian]

I'd like to reiterate that I'm only asking about what plugins should be accepted into the library. You'll want the standard issue Matej announcement about the library to make feature suggestions to.

I am merely the library gatekeeper who wishes to know what kind of plugins you want me to allow in and what kind you want kept out.

Oct 16, 2019 14:30:25 GMT -8 Brian said:

Note that these questions revolve around the acceptance of plugins to the library, not the appearance or functionality of the library itself.

[Kami]

Oct 17, 2019 14:32:54 GMT -8 Brian said:

I'd like to reiterate that I'm only asking about what plugins should be accepted into the library. You'll want the standard issue Matej announcement about the library to make feature suggestions to.

I am merely the library gatekeeper who wishes to know what kind of plugins you want me to allow in and what kind you want kept out.

Oct 16, 2019 14:30:25 GMT -8 Brian said:

Note that these questions revolve around the acceptance of plugins to the library, not the appearance or functionality of the library itself.

:P Fairy snuff, posted edited to remove the fluff.

[Chris]

Oct 16, 2019 14:30:25 GMT -8 Brian said:

Currently, any plugin that gets submitted to the library is either accepted or rejected based on whether or not it achieves the following goals:

• Adds new functionality to the forum and/or automates a layout change that would otherwise require a substantial amount of time and effort to achieve
• Contains valid, error-free code as far as testing can confirm
• Includes a relevant name and description
• Includes library images that are relevant to the plugin and meet the image resolution restriction stated in the admin area
• Sanitizes key data (if the plugin uses keys)
• Abides by the Developer Guidelines

• What goals do you believe a plugin should achieve to be eligible for the plugin library?
  In addition to the above, plugins that have been monetized, edit locked or source minified/obfuscated (I recall this being an unofficial restriction which affected at least one of Peter's plugins, but not included in the list above) should also have a github (or similar: bitbucket, sourceforge, gitlab, etc.) presence so the activity on a plugin's codebase can be ascertained and independently patched in the event an author goes missing.

  ---

  edit:
  SPOILER: Click to show
  This is what we lost going from header/footer to plugins, the ability to peer review/patch as well as give budding coders a resource to imitate and incorporate into their own codes ultimately growing the community and the number of submitted codes. Peter is a champion of this approach (and was the biggest reason I decided to get into Proboards programming). His codes were always open source for others to learn and back when he was a coding moderator he would constantly give us tips on how to optimize or correct bugs. This led to a thriving coding guild.
  
  We don't want the plugin submission process to be so onerous it discourages submissions but it should also have some protections for the community as a whole not just the author, namely timely bug fixes. Proboard pushes are going to happen and with them come bugs that weren't there prior to a push. The announcements regarding what was being addressed in each push has been abandoned leaving it up to the coder once again to figure out for themselves.
  
  The reasoning behind the pb plugin was to insulate the end user from the code and avoid cutting/pasting/modifying errors but that also hampered those that could help when problems crop up the same way someone requesting help on a forum that is closed to guests will get very limited responses.
• What should the images included alongside a plugin's library entry depict?
  screenshots of plugin in action as well as of configuration pages so consumer can determine at a glance if this is in the vein of what they were looking for but one image could also be a depiction geared more towards marketing like a cover page (logo, illustration of the concept rather than a real image just to summarize in a single pic what it would take multiple pics to convey)
• What do you believe a plugin's description should include?
  Intended usage
• Do you have any other suggestions?
  a list of classes/IDs/ancestor chains that are required to be present for the plugin to accomplish its job and aid theme creators and other plugin authors that may change these things to see off the bat that this would cause an incompatibility with this particular plugin. This could probably be semi-automated with an output of the selectors found in the code at submission time with the author able to add more that may not be obvious (e.g. contained in a var, concatenated)