Clearing "The community says it's broken"

rbrahmson

How does a developer clear that indication on the plugin addon "store"?
I upgraded a plugin to work with 2.3rc1 and I can't clear the "I am a plague" tattoo ;-)

Also, it's very discouraging for a developer to have no idea what the problem is. User's can just vote anonymously without being required to post a reason (I can live with the anonymity but not without the reason for the unerasabe down vote...)

vrijvlinder

Just click, it works… or tell us what plugin it is, and then we can try it and click it works if it does.

It is not supposed to be a decisive thing. Just that others found it did not work for them. People who don't even try to find a way to make it work , even if it's because of their own set up, probably did not need the add-on in the first place.

Maybe there should be an option to clear the poll upon update of a new version.

rbrahmson

@vrijvlinder: I don't seem to be able to clear it... The three plugins I explicitly updated and tested on 2.3rc1 are "side panel links", "Discussion Note", and "Relevant Title".

Will test the rest after I return from vacation... I may be silent on the forum for a while (and may not want to return should Trump win;-)

It would be great if there was an option for the author to clear the flag. Would be great also if Plugininfo had an entry that the author may claim the latest Vanilla version the plugin was tested on by the author.

River

@rbrahmson said:

How does a developer clear that indication on the plugin addon "store"?
I upgraded a plugin to work with 2.3rc1 and I can't clear the "I am a plague" tattoo ;-)

Also, it's very discouraging for a developer to have no idea what the problem is. User's can just vote anonymously without being required to post a reason (I can live with the anonymity but not without the reason for the unerasabe down vote...)

I agree with you it is a flawed system. Pretty much this is how it works. Some people don't care if anyone downloads their plugin. If they do great, if they don't oh well their decision. Super plugins become noticed, Mediocre plugins and esoteric plugins may get a few cheerleaders, but the majority of the user population has no need for it or the need to comment upon it, or the plugin doesn't scale well could also be a reason. IMHO, don't let your ego get in the way of your add-on, if people like it you will notice, they will want more and more features, or suggest changes. Occasionally a plugin is good and no one wants more features because it performs exactly what is needed. Most of the user population doesn't care if something works (that is their expectation), they do care if something doesn't work.

It's pretty much a no win situation in the voting arena unless your add-on is super popular and you have a few cheerleaders.

Long term broken plugins and insecure plugins should be removed from the download list, instead of a popularity vote.

I agree with you voting is broken in itself. It becomes a popularity contest or a product of apathy.

Voting on a plugin is a flawed system. What stops the original developers from saying it works, when it is broken. A developer should not be able to vote on their own plugin in my opinion.

you can react to your own post as well

https://vanillaforums.org/discussion/comment/243474/#Comment_243474

So, the community could say works great when it doesn't,

there are lots of broken plugins that no one has indicated has broken and probably people say something is broken with respect to a version of vanilla that they are not even using.

Voting on a plugin for a release candidate or a beta version doesn't tell you if it works for the current stable version.

https://vanillaforums.org/discussion/comment/239242/#Comment_239242

Then the other issue. 10,000 people say a plugin is broken om 2.0, 2.1 and 2.2, the plugin is unchanged, vanilla 2.3rc1 is released - all votes lost and 2.2 is still the stable version.

Linc

Ideally:

• Releasing a new version of the plugin should clear the vote.
• Only the latest stable and major point version of core should be recognized to vote against.

I don't think these would be challenging tasks for someone to undertake on the community repo.

vrijvlinder

@Linc said:
Ideally:

• Releasing a new version of the plugin should clear the vote.

That is what I voted/propositioned for. It would allow for a more fair vote to give the author the opportunity to mitigate.

• Only the latest stable and major point version of core should be recognized to vote against.

Yea , that is the weird part of this... :P

I don't think these would be challenging tasks for someone to undertake on the community repo.

It should only take a minute.... :P

hgtonight

@vrijvlinder said:

@Linc said:
Ideally:

• Releasing a new version of the plugin should clear the vote.

That is what I voted/propositioned for. It would allow for a more fair vote to give the author the opportunity to mitigate.

This is the current behavior. Uploading a new version updates the latest version of the plugin, which is what gets pulled by default.

River

@vrijvlinder said:

@Linc said:
Ideally:

I don't think these would be challenging tasks for someone to undertake on the community repo.

It should only take a minute.... :P

if no one takes up the challenge or if the challenge is a year-long challenge, maybe staff could undo the changes and last commmit, because it just confuses the issue whether something is broken for two reasons. both human logic as well as coding logic is broken.

• as rbrahmson said - you can click and say it is broken without giving a reason when it is not broken.

• and most of all it doesn't apply to the version that the majority of vanilla users are using. By not having it refer to the current stable version of vanilla, it is worse than not having it at all. Garbage in, garbage out. easier to get garbage data in, when it doesn't refer to the stable and hopefully most commonly used version of vanilla