As a developer, I would like to publish my plugins via a link to my version control system (git, hg, svn, etc.) so that I can easily push changes.
As a developer, I would like to add metadata to releases so I can decrease the cost of maintenance.
As a user, I would like to filter the list of plugins based on popularity so I can see the best of the best.
As a user, I would like to see an indicator of trust for a specific author/plugin. Something like "this plugin has been reported as working by x users for Vanilla Y.Z.A" would help me set expectations for the plugin.
As a user, I would like to be able to search the repository by name and description so I can quickly find plugins with keywords I am interested in.
As a developer, I prefer single addon repositories since I usually clone directly into the plugins folder on my web server for ease of updating.
I agree and that is how I have released mine.
One idea is simply to link to individual's github projects and the repos section more of a front end and list for that. But the linkage subject to checks and balances.
I was thinking mostly screenshots, changelists, and upgrade instructions.
My experience as a developer is that the PluginInfo format has limitations regard reliable and accurate information, my experience as a user is pluigns descriptions vary in their usefulness and information can become outdated. it may benefit from a standardised format and maybe some compulsory meta, and interface hints/tips to improve the quality would make sense, as well as notifications in line with version to encourage
I think some conventions for licence, changelists, readmes, screenshots, demos would be useful plus managing dependences. Where possible follow github conventions.
My experience as a developer/user is is harder to get/set accurate descriptor of version and relationships between sofware, in one case I have to put some additional code in setup.
It is also not possible to filter in the repos becuase there is no established conventions.
As an add-on consumer, I would like a good indication of whether the add-on is compatible with my version of Vanilla so that I can reduce the amount of time I spend looking at non-functional add-ons. This could include a author-provided indication (e.g. works with 2.1, doesn't work with 2.0, untested in 2.3) as well as community-provided info.
As an add-on consumer, I would like to see a demo of add-ons in action to see if the functionality is what I want. I wonder if it would be possible for Vanilla to set a up a dynamic test forum where you can choose which add-ons to activate...
As an add-on consumer, I would like to see a demo of add-ons in action to see if the functionality is what I want. I wonder if it would be possible for Vanilla to set a up a dynamic test forum where you can choose which add-ons to activate...
I think the onus should for the developer to host any demo, if applicable. Vanillaforums.org not running a dedicated PaaS which is sandboxed, so third party code can run.
@Linc said:
How do we handle security issues in third-party plugins in the directory?
I think that if it is a known security issue that has been corroborated by several people, it should be removed.
If it is a lesser security issue or it has not been corroborated, then place a notice in red "Potential security issues, use carefully" ...
It is a can of worms because if it is not removed, people will blame Vanilla for distributing hazardous plugins even if nothing happened while using it.
Maybe the best thing is to try to get ahold of the author and if they don't reply within a certain time period, then remove the plugin in question. If they come back and plugin is gone, they can re upload a new updated version.
Removal, as it currently stands, means permanently deleting the addon and all associated discussions, revisions, etc are cast to the wind. It also unregisters the namespace so it can be taken by anyone else.
@Linc said:
How do we handle security issues in third-party plugins in the directory?
It depend on how the Addons directory would work, many addons are hosted also on github, and this may be how you would be integrating. But regardless you cannot control this except for asking for cooperation and fostering that.
I think what is good for the goose is good for the gander. I'd hold the same standard for the core to the addons listing IMO.
I think you can suspend rather remove permanently problematic addons, give them opportunity to learn and improve.
I personally think that having a security issue tracker for security issues for the core and addon will help, where discussion of issues would be available to project developers and developers, in confidence. Why? Yes they are third party, but the same time it is extending the functionality and using the framework. It would help foster this cooperation, and sense of developer community.
Personally I think it would help with various things including security if there was a closer coupling between version of the core and vanilla, even if this mean more work for me.
@Linc said:
Removal, as it currently stands, means permanently deleting the addon and all associated discussions, revisions, etc are cast to the wind. It also unregisters the namespace so it can be taken by anyone else.
Removal is a strong option, should be a last resort.
Though I don't really see an issue with pruning addon which aren't maintained.
I do think though you need to keep developers engaged and give them an opportunity to move with you.
@Linc said:
Removal, as it currently stands, means permanently deleting the addon and all associated discussions, revisions, etc are cast to the wind. It also unregisters the namespace so it can be taken by anyone else.
Ok, how about archiving it ?
I mean if the issue is serious enough, removal should be the only option.
Otherwise just placing a notice of potentiality and emailing the author should be enough.
@Linc said:
How do we handle security issues in third-party plugins in the directory?
Moderation could be partially automated via the compatibility poll. Hit enough "this doesn't work" or "this is really risky" and the addon gets buried, like I have seen on some of the hosted platforms with negative reactions.
The developer would get a notification one of their addons was buried automatically and requires them addressing the issue/putting out a new version.
Maybe have an audit poll as well? I can't see it honestly getting used a lot by the layperson. Probably use some of the tools GitHub provides.
Moderation could be partially automated via the compatibility poll. Hit enough "this doesn't work" or "this is really risky" and the addon gets buried, like I have seen on some of the hosted platforms with negative reactions.
This is subject to abuse.
The problem is the average user doesn't know if a plugin is risky, and it can sit there for years.
The Basic Premise should be An uploaded plugin works.
A the more positive response "Yes" or "Great" the more credence.
B When something works - you don't need to explain why.
C When something doesn't work - you do need to give the reasons, to give credence to your remark
D When something is insecure - you also need to give a reason why you came to that conclusion.
A, B - could certainly be a positive reaction counter.
C - definitely needs a comment
D - definitely needs a pm to Vanilla Staff - And action should be taken - if true.
Some things should not be automated in my mind. Human logic is subject to enough mistakes without coding logic added in.
If something is reported as insecure, it should be taken out of the add-ons or a giant WARNING in description
Then a period of time as Lincoln Suggested - A month to send Author a message or find someone willing to take on the necessary rewriting. If Author doesn't reply within a month or no one is willing to take the plugin and refurbish. So be it. It will be an incentive to visit the board more frequently.
Its not like there have been a whole lot of plugins that have been reported with security risks.
As far as I know just tagging, kpoll, and poll were reported.
On a side note - to me this would greatly improve things and properly categorize things.
I think a there should be a reaction or minion like response - that says "Ask your question under the plugin" and that a moderator can click that automatically closes discussion
and another that does the same if the version number is not entered. - "Please enter your version number and start a new discussion, that explains how to find your version number and closes the discussion as well.
eventually these two reactions will alert people to post in areas that will make it easier for other people to find.
Anything with these two reactions that is closed can be automatically deleted in 7 days.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
@Bleistivt said:
Great integration into Vanilla (discussions can be attached to addons, addons appear on the user page and in activity)
Do we think this is a requirement for the next iteration?
As an administrator, I find the glut of plugin-related bug reports in the main discussions list to be an unfocused annoyance. I'd much rather see plugin & theme feedback as GitHub issues where the author runs the show.
Do we think this is a requirement for the next iteration?
I would love to see some Vanilla/GitHub integration. Something like "File a bug report" that just pre-fills an issue request with the discussion title and/or selected text and has a link to the discussion in the issue.
Most bug reports start as a discussion like "This isn't working". 5 comments in and we have something worth reporting. Moving that discussion off of the Vanilla platform seems... wrong?
As an administrator, I find the glut of plugin-related bug reports in the main discussions list to be an unfocused annoyance. I'd much rather see plugin & theme feedback as GitHub issues where the author runs the show.
This would also remove the incentive of participating in this (vf.org) community. Most people filing issue reports aren't developers. They probably don't have a GitHub account.
Comments
As a developer, I would like to publish my plugins via a link to my version control system (git, hg, svn, etc.) so that I can easily push changes.
As a developer, I would like to add metadata to releases so I can decrease the cost of maintenance.
As a user, I would like to filter the list of plugins based on popularity so I can see the best of the best.
As a user, I would like to see an indicator of trust for a specific author/plugin. Something like "this plugin has been reported as working by x users for Vanilla Y.Z.A" would help me set expectations for the plugin.
As a user, I would like to be able to search the repository by name and description so I can quickly find plugins with keywords I am interested in.
Do these make sense as user stories?
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
Those are perfect examples of stories @hgtonight. Couple of questions.
As a developer, I want to put multiple or just one addon in a repo?
Can you expand on what you mean by metadata?
As a developer, I prefer single addon repositories since I usually clone directly into the plugins folder on my web server for ease of updating.
I was thinking mostly screenshots, changelists, and upgrade instructions.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
I agree and that is how I have released mine.
One idea is simply to link to individual's github projects and the repos section more of a front end and list for that. But the linkage subject to checks and balances.
My experience as a developer is that the PluginInfo format has limitations regard reliable and accurate information, my experience as a user is pluigns descriptions vary in their usefulness and information can become outdated. it may benefit from a standardised format and maybe some compulsory meta, and interface hints/tips to improve the quality would make sense, as well as notifications in line with version to encourage
I think some conventions for licence, changelists, readmes, screenshots, demos would be useful plus managing dependences. Where possible follow github conventions.
grep is your friend.
My experience as a developer/user is is harder to get/set accurate descriptor of version and relationships between sofware, in one case I have to put some additional code in setup.
It is also not possible to filter in the repos becuase there is no established conventions.
grep is your friend.
As an add-on consumer, I would like a good indication of whether the add-on is compatible with my version of Vanilla so that I can reduce the amount of time I spend looking at non-functional add-ons. This could include a author-provided indication (e.g. works with 2.1, doesn't work with 2.0, untested in 2.3) as well as community-provided info.
As an add-on consumer, I would like to see a demo of add-ons in action to see if the functionality is what I want. I wonder if it would be possible for Vanilla to set a up a dynamic test forum where you can choose which add-ons to activate...
I think the onus should for the developer to host any demo, if applicable. Vanillaforums.org not running a dedicated PaaS which is sandboxed, so third party code can run.
grep is your friend.
How do we handle security issues in third-party plugins in the directory?
I think that if it is a known security issue that has been corroborated by several people, it should be removed.
If it is a lesser security issue or it has not been corroborated, then place a notice in red "Potential security issues, use carefully" ...
It is a can of worms because if it is not removed, people will blame Vanilla for distributing hazardous plugins even if nothing happened while using it.
Maybe the best thing is to try to get ahold of the author and if they don't reply within a certain time period, then remove the plugin in question. If they come back and plugin is gone, they can re upload a new updated version.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Removal, as it currently stands, means permanently deleting the addon and all associated discussions, revisions, etc are cast to the wind. It also unregisters the namespace so it can be taken by anyone else.
It depend on how the Addons directory would work, many addons are hosted also on github, and this may be how you would be integrating. But regardless you cannot control this except for asking for cooperation and fostering that.
I think what is good for the goose is good for the gander. I'd hold the same standard for the core to the addons listing IMO.
I think you can suspend rather remove permanently problematic addons, give them opportunity to learn and improve.
I personally think that having a security issue tracker for security issues for the core and addon will help, where discussion of issues would be available to project developers and developers, in confidence. Why? Yes they are third party, but the same time it is extending the functionality and using the framework. It would help foster this cooperation, and sense of developer community.
Personally I think it would help with various things including security if there was a closer coupling between version of the core and vanilla, even if this mean more work for me.
grep is your friend.
Removal is a strong option, should be a last resort.
Though I don't really see an issue with pruning addon which aren't maintained.
I do think though you need to keep developers engaged and give them an opportunity to move with you.
grep is your friend.
Ok, how about archiving it ?
I mean if the issue is serious enough, removal should be the only option.
Otherwise just placing a notice of potentiality and emailing the author should be enough.
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
Moderation could be partially automated via the compatibility poll. Hit enough "this doesn't work" or "this is really risky" and the addon gets buried, like I have seen on some of the hosted platforms with negative reactions.
The developer would get a notification one of their addons was buried automatically and requires them addressing the issue/putting out a new version.
Maybe have an audit poll as well? I can't see it honestly getting used a lot by the layperson. Probably use some of the tools GitHub provides.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
This is subject to abuse.
The problem is the average user doesn't know if a plugin is risky, and it can sit there for years.
grep is your friend.
So you either weight the user's responses, or make the appeal process simple. Reduce the incentive and have a manual reversal option.
Users are always going to abuse/misuse tools. Still need the tools.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
thoughts here:
The Basic Premise should be An uploaded plugin works.
A the more positive response "Yes" or "Great" the more credence.
B When something works - you don't need to explain why.
C When something doesn't work - you do need to give the reasons, to give credence to your remark
D When something is insecure - you also need to give a reason why you came to that conclusion.
A, B - could certainly be a positive reaction counter.
C - definitely needs a comment
D - definitely needs a pm to Vanilla Staff - And action should be taken - if true.
Some things should not be automated in my mind. Human logic is subject to enough mistakes without coding logic added in.
If something is reported as insecure, it should be taken out of the add-ons or a giant WARNING in description
Then a period of time as Lincoln Suggested - A month to send Author a message or find someone willing to take on the necessary rewriting. If Author doesn't reply within a month or no one is willing to take the plugin and refurbish. So be it. It will be an incentive to visit the board more frequently.
Its not like there have been a whole lot of plugins that have been reported with security risks.
As far as I know just tagging, kpoll, and poll were reported.
On a side note - to me this would greatly improve things and properly categorize things.
I think a there should be a reaction or minion like response - that says "Ask your question under the plugin" and that a moderator can click that automatically closes discussion
and another that does the same if the version number is not entered. - "Please enter your version number and start a new discussion, that explains how to find your version number and closes the discussion as well.
eventually these two reactions will alert people to post in areas that will make it easier for other people to find.
Anything with these two reactions that is closed can be automatically deleted in 7 days.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
true but it doesn't solve the problem we have here. user will use the plugins they think are good they don't think about if it is risky.
There has to be responsible declaration for this in the know, that is reproducible.
grep is your friend.
Do we think this is a requirement for the next iteration?
As an administrator, I find the glut of plugin-related bug reports in the main discussions list to be an unfocused annoyance. I'd much rather see plugin & theme feedback as GitHub issues where the author runs the show.
I would love to see some Vanilla/GitHub integration. Something like "File a bug report" that just pre-fills an issue request with the discussion title and/or selected text and has a link to the discussion in the issue.
Most bug reports start as a discussion like "This isn't working". 5 comments in and we have something worth reporting. Moving that discussion off of the Vanilla platform seems... wrong?
This would also remove the incentive of participating in this (vf.org) community. Most people filing issue reports aren't developers. They probably don't have a GitHub account.
Vanilla is more friendly than GitHub, imo.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.