Addons directory, version 2

Linc

I have some open-ended questions for our open source team about the Addons directory here.

• What does an MVP (minimal viable product) for a new Addons directory look like?
• What current strengths should be preserved; what weaknesses must be addressed?
• What would your involvement in a development project to replace it look like?

What else should we talk about before we start planning?

Linc

To get things started:

1) I think it should be GitHub-dependent. I want to see every addon we make available for download here to have a repository we can see. That's a security feature to an extent (we can see changesets), but mostly so there's a dedicated issue tracker where we can communicate with the authors. Our discussions list is jammed with addon issues that don't belong here. Releases should be GitHub-based too, without requiring manual uploads to our server.

This does add a git knowledge requirement to being part of the directory, but I think GitHub has the tools now where even a novice can get going with it quickly.

2) A WordPress-like "compatible with" poll would be a welcome replacement to the unscalable "approved by Vanilla" mechanism.

R_J

Filter by Vanilla subversion
Validation/Recommendation by vanillaforums.org users ("Validated by User A, User B, User C; Recommended by User C"). 5 star rating would be nice.
Upload by pasting GitHub link (autifill link to project)
Design: make "Ask a Question" more prominent. Shouldn't it be class Button Primary?

Concerning involvement: I can give feedback, but I do not think I'm qualified to work in a bigger project, though looking at some issues should be no problem.

Linc

@R_J said:
I do not think I'm qualified to work in a bigger project

http://en.wikipedia.org/wiki/Dunning–Kruger_effect

The Dunning–Kruger effect is a cognitive bias manifesting in unskilled individuals suffering from illusory superiority, mistakenly rating their ability much higher than is accurate. [...] Meanwhile, people with true ability tended to underestimate their relative competence

We were just discussing the relationship between this and our issue tracker at the office today.

x00

A tighter versioning system and possibly a more closely coupled relationship between version of the framework and Addons. Filtering on the interface to do with that.

Bleistivt

Current strengths

• Great integration into Vanilla (discussions can be attached to addons, addons appear on the user page and in activity)
• Easy to upload an addon and add a description
• Filter options for Applications, Themes, Plugins

Current weaknesses

• No source control integration
• lacks polish in some places (addon description textbox very minimal, vanillicons not shown in the attached discussion list)
• No way to delete and manage screenshots. I think, if the description editor would support image uploads, the images could just be added to the description and the screenshots-section could be taken out (large images like theme previews would still have to be fancyboxed, though).

Suggestions

@R_J said:
5 star rating would be nice.

While ratings would be cool, I think users should only be allowed to give a rating, when they also write a small review.
What I see a lot in the Wordpress addons repo are plugins with a low star count but no indication why.
(Sure, there will still be the "doesn't work" reviews, but you could at least reply to those.)

While making the releases entirely github based is a good idea, I think a certain directory layout has to be enforced.
There's the temptation to simply upload the zipped master, but that will only result in people failing to install the addon as the folder is called pluginname-master.

hgtonight

Assuming you are going to use git/GitHub, an MVP must have the following:

• vf.org user mapped to github.com user in a verified way

• default repo structure
  ** aim to pull extra metadata from the repo (screenshots, readme description, hi-res icon, etc.)
  ** Makes sense to users cloning the repo directly

• compatibility poll

• auto-linking to dependencies if they are in the directory
• search name and description

Some nice to haves:

• trigger directory update from commit message
• changelist generation
• ratings/reviews
• donation links (gratipay, paypal, etc.)

I would think you would need either a) a hooks script to copy into a user's git repo or b) some documentation on how to set up github webhooks

It would be great if the project requirements, once set, were public and then development was done by the entire community.

Linc

@hgtonight said:
It would be great if the project requirements, once set, were public and then development was done by the entire community.

Who the hell else do you think is volunteering for this mess?

Adrian

All great ideas here, one I see missing is some sort of way to know a new version is available.

hgtonight

@Linc said:
Who the hell else do you think is volunteering for this mess?

https://www.youtube.com/watch?v=5KPT5657XD0

I hope your body can take it.

Bleistivt

Just had an idea: To make it more vanilla-ish, instead of ratings, it'd be cool if people could react to plugins. There could be reactions like "Works", "Incompatible", "Don't understand", "Ate my cat",... etc

vrijvlinder

@Bleistivt said:
Just had an idea: To make it more vanilla-ish, instead of ratings, it'd be cool if people could react to plugins. There could be reactions like "Ate my cat",... etc

This reaction means it could be hazardous .. STAY AWAY

Linc

Let's back up a little and re-approach it from this angle: http://vanillaforums.org/discussion/28023/user-stories-feature-development

What are some user stories for the addon directory?

Bleistivt

When I decided to switch to Vanilla, I tried to ease the transition for my users by installing plugins for the features they've grown accustomed to, first.

I filtered the addons by "Most Popular" and went through the first 3,4 pages until I found everything I needed (Quotes, FileUpload, WhosOnline, Signatures, etc.)
Most of the plugins had flaws though, bugs that were mostly already fixed for the version in the addons repository (which I didn't know of).

• I missed out on a lot of great plugins, because mostly plugins, that have been there since 2011 have the chance to rise to the top pages
• I installed old version of plugins with annoying bugs

So yeah, source control integration is a top priority, I'd even go as far to say that if only a single feature could be implemented for version 2, it should be the github integration.

The most popular option should have a filter like "most popular last week/month/year"

The "Approved by Vanilla" didn't really make an impression on me, when I noticed the majority of the plugins just weren't approved.

Unrelated question:
When will development start?

peregrine

I second @Bleistivt's notion with a twist.

from a user story as an admin.

lots of people are forced to go to github to get reliable working versions of add-ons developed by staff for vanilla 2.1
and some also need tweaks as well.

IMHO, I still wonder what the reasoning is , or the problem, or the need to do a major overhaul, just to put working versions of staff related plugins in the add-ons section. An overhaul need not and should not pre-empt the upgrading of downloadable working plugins from http://vanillaforums.org/addons.

As far as automatically adding user donated plugins to github. I am not a fan (and probably a minority). If a an author maintains plugins and upgrades and doesn't have reasonable means to use github or the knowledge, it doesn't help.
All plugins submitted by users are not something that was agreed upon by the authors uploading the plugin. They may not want it on github for one reason or another, and they still may maintain it. I think express consent to place on github should be opt-in rather than opt-out.

The add-ons repository - should be the DE FACTO area for a working version of the add-on with 2.1

e.g. Qna need upgrading and/or synched with the add-ons section

Whosonline, Pockets, and Fileupload to name just a few. or moved to the recent

some may need to be tested and fixed.

e.g. some actually work correctly ...

But I see no compelling reason to have to go to github for Pockets, since the github version works fine in 2.1 , yet in the add-ons section it is outdated.

peregrine

Another suggestion is remove the approved label currently and change all staff created plugins to "Vanilla Staff Created"

and the rest "Community Developed"

then people will not get scared off by Approved vs non-Approved.

In addition some plugins may work fine for small communities but not work great with large communities.
Scalablility may not be the best indicator for approval. but could be noted that the plugin may not be suitable for large communities and cause a performance drag. At the same time it may be the ticket for functionality needed for a small community.

Currently, An approved plugin may become NOT approved. just by making a simple change of version number without any other changes,

vrijvlinder

@peregrine said:
Another suggestion is remove the approved label currently and change all staff created plugins to "Vanilla Staff Created"
then people will not get scared off by Approved vs non-Approved.

Yes or make the approved ones fail proof and updated guaranteed or your money back kind of thing....

I would like there to be some form of getting feedback from people who download. I can't believe I have say 2k downloads and only 4 complaints ...

peregrine

test quoting erratic. need to copy and paste.

@vrijvlinder said:
I would like there to be some form of getting feedback from people who download. I can't believe I have >say 2k downloads and only 4 complaints ...

99% of the time the only way anyone makes a comment is if they want a modification, or have a complaint or found a bug. Positive user feedback is about as sparse as trying to get anyone to participate in a community thread seeking non-developer user input. but thats another story.

edit block-quote first - sentence above is not in the quote.

vrijvlinder

Yea that has happened to me too where I quote but the body is missing, sometimes it takes a bit to appear sometimes not at all and I must copy paste...

peregrine

need to copy and paste if trying to quote this comment...

http://vanillaforums.org/discussion/comment/216249/#Comment_216249

perhaps if it starts with a blockquote - it ignores the rest.

thought it had to do with last comment but not really

Linc

The blockquote bit is a Markdown + Quotes bug, I believe. Would be a good item to pursue here perhaps: http://vanillaforums.org/discussion/27981/upgrading-markdown-lib