Possibility of Github moderation for community members

[TwizzyDizzy]

Added another one (maybe the most important one) for missing issue templates.

Issue: Streamline reactions: notemplate+close

I have just closed #9598 with this template, let’s see the reaction. By the way: I also loosely collect some topics that come up again and again and also some meta-patterns that cover how “we” react to issues and how those patterns contribute to such a large amount of open issues. I’ll share them in time.

Cheers
Thomas

[sing.li]

@gabriel.engel we would to hear what you think.

[sing.li]

It seems @sean.packham may be working with you guys on this. Stay tuned.

[JSzaszvari]

Thats awesome, Good stuff !!

[JSzaszvari]

@sing.li

Let’s see if we can have someone from our side to look after the issues and roll in @JSzaszvari

Thanks, I appreciate it

@TwizzyDizzy - I’ll shoot you a message on open.rocket.chat so we can touch base

[TwizzyDizzy]

@TwizzyDizzy

Also you have to be clear in communication.

• you have to close issues that are none (if it’s easy to verify this by quickly scanning the issue)
• if you find a feature request to be nice, but don’t have time to work on it now, label it with “will-do-later” and close it (ideally with a reaction template of course, explaining that you might get back to it if there’s time)
• if you find a feature request to be nice, and have time to work on it now, label it with “will-do” and assign it to a milestone.
• if it’s a support request, label it as “support” and close it (ideally with a reaction template of course, telling the people to search for help in the forums or the #support channel)

I think I’d like to add a fifth and sixth point:

• if you don’t think, that a new feature proposal/request fits in your overall plan for Rocket.Chat, make it clear to the one requesting that feature and explain why you won’t implement this. Add a label wont-do and close it.
• if a feature will not be implemented by you because of time constraints (meaning it fits in the overall plan but other things are more important right now), add a label pr-welcome. Not really sure whether to close it at that point or not, needs some thought.

This, of course, assumes, that there is an overall plan, a roadmap of some kind. From only looking at github (and I don’t want to sound offensive with that in any way) I don’t get the feeling that there is a clear direction on the basis of which you could acknowledge or decline the implementation of a new feature(-request).

That being said, I think currently it’s also pretty hard, given the excess amount of open issues. I assume there is an internal roadmap, so maybe it’s worth a thought whether to publish (even parts of) it so you can refer to it when declining feature-requests.

Cheers
Thomas

[JSzaszvari]

@TwizzyDizzy

if you don’t think, that a new feature proposal/request fits in your overall plan for Rocket.Chat, make it clear to the one requesting that feature and explain why you won’t implement this. Add a label wont-do and close it.

Have to say, I agree here. There’s a lot of stuff thats open and un-closed PR’s of stuff thats been tagged as a feature request or submitted that are not really feasible or a bit too limited in scope, ie stuff that would only benefit a very small subset of users.

I wonder if theres a module/plugin for this forum where we could integrate the feature requests and have a voting system, simple upvote and downvote. Theres no real way to gauge demand of a feature request at the moment except for the amount of activity in the GitHub request

edit: Hmmm GitHub - discourse/discourse-topic-voting: Adds the ability for voting on a topic within a specified category in Discourse.

[TwizzyDizzy]

@JSzaszvari

stuff that would only benefit a very small subset of users.

Yep, that’s a very common theme, true.

@JSzaszvari

I wonder if theres a module/plugin for this forum where we could integrate the feature requests and have a voting system, simple upvote and downvote. Theres no real way to gauge demand of a feature request at the moment except for the amount of activity in the GitHub request

To be honest, I think if you want something like that, why not do it directly in Github issues instead of forcing the user to switch tools.

We could make it official policy: “thumb up” = I want this, too … and so forth…

Cheers
Thomas

[JSzaszvari]

@TwizzyDizzy

To be honest, I think if you want something like that, why not do it directly in Github issues instead of forcing the user to switch tools.

We could make it official policy: “thumb up” = I want this, too … and so forth…

Whilst not completely opposed to that, I feel like sometimes it’s not to effective with really large projects with lots of issues, kind of a case of “I’ll never see that feature as its on page 22 of the issues” and good features might be forgotten about because they require a significant time commitment to complete, and the longer it takes, the deeper it falls into the pages and then gets forgotten about (Hope that makes sense?)

With a up-vote downvote kind of system the issues that are most requested/most important to the majority of the public who have voted sit at the top. I think it makes it much easier to gauge how much demand there is for something.

Even at the moment, you’ll get a feature request now, which gets approved whilst feature requests with 100+ thumbs up are sitting on on page 78 of the issues page and have been long forgotten about.

Anyways, Not opposed to doing that way. I’m just more used to that with the work that I do, I’m in JIRA a lot of the day and am used to the concept of “voting” for issues that get worked on. Just my personal preference. not necessarily whats best

[JSzaszvari]

So I just had a quick look, I had no idea this was possible.

But if you use the following filter in GitHub issues it actually sorts by number of thumbsups’

is:issue is:open sort:reactions-+1-desc

Pretty much mitigates everything I said except the issue of the average person just browsing being able to see what the most popular ones are and only seeing the first few pages of feature requests/new stuff vs what other people are voting for

[JSzaszvari]

@sing.li

our GitHub stats is becoming an integral part of our profile/identity/merit

@sing.li could not agree more. I’ve hired people for my team before even seeing their resume because I’ve seen their github first.

[TwizzyDizzy]

Hey @JSzaszvari!

@JSzaszvari

Whilst not completely opposed to that, I feel like sometimes it’s not to effective with really large projects with lots of issues, kind of a case of “I’ll never see that feature as its on page 22 of the issues” and good features might be forgotten about because they require a significant time commitment to complete, and the longer it takes, the deeper it falls into the pages and then gets forgotten about (Hope that makes sense?)

True, but I think one can mitigate that by simply assigning an issue to a milestone (might also be a meta-milestone like “long-term” or “mid-term” or “next-up”) after voting has been done (whatever time-span that may be).

@JSzaszvari

So I just had a quick look, I had no idea this was possible.

But if you use the following filter in GitHub issues it actually sorts by number of thumbsups’

is:issue is:open sort:reactions-+1-desc

Ah! Nice indeed… didn’t know either, that you could sort by thumb-ups. Given the excess amounts of issues though, I think this can only really get into action once the number of issues has been reduced massively.

@JSzaszvari

Pretty much mitigates everything I said except the issue of the average person just browsing being able to see what the most popular ones are and only seeing the first few pages of feature requests/new stuff vs what other people are voting for

Unfortunately, I think this is something one can’t prevent in any way. At least nothing comes to my mind right now. But getting those people aboard, who have a little more dedication or interest at least for some topics is better than nothing

Cheers
Thomas

[TwizzyDizzy]

New bot template:

Issue: Streamline reactions: nosupport+close

Cheers
Thomas

[sing.li]

@JSzaszvari Sorry for the delay and runaround. Please contact @theo.renck to get on the beta with the moderation bot.

@TwizzyDizzy Can you please help @JSzaszvari to start working with the bot.

[TwizzyDizzy]

@sing.li

@TwizzyDizzy Can you please help @JSzaszvari to start working with the bot.

Theo has mentioned everything you can do with the bot in this comment. The configuration of the bot itself is to be found here.

Also here’s the list of issues I closed with the bot already (mostly using the templates manually).

If you need any help beyond that, @JSzaszvari, just get back to me

Cheers
Thomas

[sing.li]

Awesome as usual, thanks @TwizzyDizzy !

@Antgel , another long time contributor to Rocket.Chat who had requested similar capabilities a year back, may also join the action.

[TwizzyDizzy]

Hi @sing.li (and /cc @sean.packham),

straight up question: will the mechanism of reaction templates be adopted (maybe even internally) or not? If not, I will stop any effort going in that direction.

I also need someone to have a look at (and approve, if agreed) this pull request.

Thanks in advance
Thomas

[aaron.ogle]

I personally worry a bit about the contributions: only core team

Add new feature labels and rename "help wanted" label

I hate to discourage people from trying a feature. We’ve had some amazing features added by very talented people. Features we previously planned to do eventually and would have likely marked with something like that and scared them away.

[TwizzyDizzy]

@aaron.ogle

I hate to discourage people from trying a feature. We’ve had some amazing features added by very talented people. Features we previously planned to do eventually and would have likely marked with something like that and scared them away.

Agreed. I imagine this to be used very rarely (and maybe we just don’t activate it for the community/me and only for core-team) … I thought that it might make sense with some overarching topics and stuff you want (for whatever reason) to implement yourself (maybe because it is a task in a process that should go into a very specific direction you as core members imagined).

The usual default would be “Contributions: welcome”, of course.

Cheers
Thomas

[sing.li]

@TwizzyDizzy, @theo.renck probably has the best visibility into if reaction template is on the schedule, the roadmap, or be on the WANTED-FROM-COMMUNITY list.