We’ve just opened up the long-dormant #feature:integrations category to the general public.
This category is running with @joebuhlig’s Feature Voting plugin enabled. We’ve officially adopted this plugin, and will be working together with Joe to make it stable enough for use with our hosted customers.
Go test things!
Go to the #feature:integrations category and vote your heart out. Do weird things; break it. Add new integrations for people to vote on.
Bug reports or feature requests should be posted to the plugin’s own topic.
Questions about the voting process here on Meta can be asked here in this topic.
The future of the Integrations category and the use of Feature Voting on Meta is not yet determined.
OK, now that we’ve gotten it pared down to a reasonable state, @sam had the following feature requests he wanted to get to:
Replace “Top” with “Voted” on “voting” categories.
Suppress likes on OP for “voting” topics
Sane behavior when you reach your limit, “You can not vote anymore, here is a list of stuff you voted for”
Handle edge case, deletion does not reclaim votes
Strip useless words off screen that shows who voted
One note, every time you vote it should tell you how many votes you have remaining. I had no idea votes were even limited in this manner. Something like.
You’ve cast 3 of your 5 available votes.
And
You’ve cast 5 of your 5 available votes. To cast more or change your votes … {blah}
Also @erlend_shthis is a fork and will remain a fork, so I think it deserves its own topic, like discourse-official-feature-voting or similar? I believe there’s been a bit of a misunderstanding on where comments should go, because this plugin has significantly different functionality in first party delivered form…
OK then I recommend removing the old topic and creating a new one @erlend_sh – we’re rebooting this. It will be confusing to find old out of date info…
Ok, once there’s a new topic let’s link to it, close the old one and eventually archive and unlist it. There are lots of discussions and ideas worth holding on to there, so I definitely don’t want to delete it completely.
I think this is a general problem lots of our plugins have, also discourse solved has it, mountains of irrelevant out of date discussion, it’s like each plugin struggles to be a category but is trapped in a topic
I don’t like the practice of completely erasing good deeds from history. @joebuhlig deserves a lot of credit for taking my spec and building a fully functional plugin. Loads of other people helped test and reported bugs. The likes that were doled out during this back and forth had meaning; they were by and large acknowledgements of various contributions.
The problem is this old out of date information is penalizing all future visitors, forever. So there is a rather steep (and forever growing!) cost to retaining it. As Spock once said, the needs of the many outweigh the needs of the few.
The only way to do what you propose is to completely disallow it from appearing in any search… somehow. I don’t think archiving and unlisting do that.
Unlisting is still not what is desired, you want to still show off that you had a +20 likes post, but we don’t want people to find it outside of visiting your profile, graveyard or badge list
Unlisting hides from search, badge queries and user page
I’m confused by this ‘family’ discussion. For a moment, it looked like it ended abruptly without any resolution which made it look like the discussion went off-line.
@codinghorror, out of date information is rife in meta.discourse so why is it such a problem for #plugin?
@erlend_sh, what is wrong with deleting out of date information that only had value at the time and would now confuse searchers? I read the topic and most of it will not be missed.
Plug-in release topics as a partial solution?
I wonder if this is at all related to Discourse having #releases as a canonical record of feature changes? If so then wouldn’t this be an option for official plug-ins to have release topics too?
This would more clearly indicate that development of the plug-ins is structured and important enough to record succinctly and permanently. This would also allow contributions to be given prominence in perpetuity.
If the original topics are retained then they could be closed with a link to the release topic.
Of course I’m biased, but why not rename the original topic to deprecated, close it, and create a new supported plugin topic? That process is done elsewhere. The only difference being the plugin category.
Because it clutters search results with irrelevant, obsolete information for eternity. That is my main objection. We could move it to the lounge so it won’t get indexed.
At what point do you go back and filter out old topics? I run across outdated code here on Meta all the time. That’s the nature of development. Things progress and old methods no longer work. Rather than try to hide or delete all the old information, wouldn’t it make more sense to flag it in some way (rename it and close it) and give people a way to get to the new information (create a new topic and link to it from the old).
If I understand your logic correctly (and I’m not sure I do), wouldn’t that mean you need us to start flagging topics that contain obsolete information?
I’m not an SEO expert by any means but I’ve always assumed that Google prefers new content to old. By closing the old and sending users to the new, wouldn’t you be weighting the search results to the update information anyway?
You understand these things a lot better than I do. I’m simply struggling to follow your rationale here.
