Possibility of Github moderation for community members

Community Support
1

Folks,

I was wondering: Does the Github permission model for a project allow for you to give me issue moderating privileges and would be willing to give them to me? In the past I have often had the issue that I thought that an issue might not be relevant anymore and therefore can be closed… or might even be no RC issue at all. I would promise to:

  • Be kind to the people (in the past I have sometimes been a bit snappy, when an issue clearly was no RC issue or when the person was unfriendly or demanding). I will be better at this.
  • Always clearly indicate that I am no member of the RC Core Team and therefore do not speak for the team
  • Get back to a member of your team, if I think a topic needs team input
  • Enforce the issue template in friendly manner

What do you think? :slight_smile:

A bit of background on myself: I’m a systems engineer based in Berlin, Germany and am running a small-sized RC instance (~70 users online, 250 users registered) at my company. I think I’m pretty good at debugging and grasping what a person means in their issue. I also have a good grasp of UI/UX, as I’m officially a media designer (I learned that stuff but it’s not my job nowadays).

Cheers
Thomas

2

@TwizzyDizzy we have been seriously looking into accommodating it. At this time we have not been able to find a GitHub permission / administrative settings combination that will accomplish the above. If you have any ideas or find anything from the GirHub documentation - please let us know. Meanwhile, we will continue to experiment internally to seek workable alternatives.

3

Mhhh… since I assume you run an organizational account, it looks like the “Read permissions” would do it without granting too much privileges: https://help.github.com/articles/repository-permission-levels-for-an-organization/

Ah, damn it. Nope. Closing would require write permissions which also allow pushing to repositories.

Seems like they’re also aware of this and suggest the following: https://help.github.com/articles/creating-an-issues-only-repository/ … but that’s a rather weird solution and would cause more confusion than anything else…

And I guess granting those write permissions with me pledging to touch nothing else than issues is out of the question, right? Wouldn’t judge you if so, I would be weary too, if it was my organisation…

4

Exactly. That’s where we have ended our last round of “investigation” and discussions on the topic :disappointed: Thanks for the understanding though. Please keep exploring and share - and we’ll do same.

5

I think we currently are investigating probot. Basically whitelisting trusted community members to be able to close out issues via the bot

6

Ah! Haven’t thought about it from that angle… that looks promising indeed.

7

The only sticking thing, and one that prevented us from moving forward with it, @TwizzyDizzy, is that the bot will get all the credit of doing the work on GitHub. While the tirelessly hard working contributor remains anonymous (unless one looks really hard at each case). We thought this may be a disincentive in the (general) longer term. WDYT?

8

You’re right, this is indeed a little bummer. Nobody contributes for fame, but at least one wants to have it attributed to one’s name in some way. I haven’t had a deeper look at this bot, yet I would be irritated if it didn’t incorporate the possibility to somehow have a message attached with it’s action, attributing it to an @username …

But: I think in the general use case, it should still be pretty obvious, because the contributer would justify the close with a bit of prose from his own account beforehand and just after that would trigger the bot, so I think this is not such a big issue overall…

9

@Marcelo is it possible to bring theo to this server and this channel ( TwizzyDizzy - theo is working with the bot)?

@TwizzyDizzy Here is food for thought. Perhaps orthogonal to the discussion. But trending in this code-centric mainstream open source world that we live in is a growing sort of superficiality - where GitHub stats (currently) rules the day. Whether it is the guy we report directly to, or just an acquaintance pinging in from LinkedIn - our GitHub stats is becoming an integral part of our profile/identity/merit. As Rocket.Chat grows in size, we’re feeling pressure that even we ourselves are being forced to adopt this superficiality. And here is where your opinion really counts - as you are one of the few community contributors who is blocked by this GitHub limitation - does it really matter?

10

Wellll… here’s my four-part answer:

First - “Superficiality regarding the mere quantity of contributions”:

I don’t know whether I have an opinion that reflects the overall state of this phenomena, yet I don’t feel it that much over here in Europe… but then again, I haven’t switched my daytime job in 3 years so maybe this has changed. It may just be a difference concerning the nature of somebody who is judging you. From a startup world? Yeah, maybe people from that reality are more prone to this phenomena. I myself am not so much involved with this whole startup hype, as I dislike many ideas and concepts revolving around it (VC, monetarization, people feeling somehow more “hip” and “fancy” because they work at a start up for nothing, but are part of “the next big thing”). I mainly contribute to software/projects, because I support the cause of a software and because I want the world to have proper FOSS alternatives to vendor lock-ins and SaaS and centralized services. From that perspective, I couldn’t give less of a shit whether my name is mentioned or not.

Second - Quantity over quality:

This, I think, is the effect of the neo-capitalist, number-focussed mindset trickling into the open source world. We unlearn the ability to judge others by other means than numbers - for example their friendly and social behaviour in a community (giving people JOY of being part of a group of contributors). Or the on-point quality of pull requests. Those things can’t be captured in numbers, yet are not seldomly more important than the actual figures.

Third - Does a falling tree make a noise if nobody hears it

I would call it the instagram-phenomena. There are lots of reasons why people to this:

  • Some want to share their life with their friends & family
  • Some want to project an image of themselves to the world
  • Some want third parties to get a quick grasp of what they do

… I think all of the above reasons are, in itself, legit motivations. The overall topic is, I think, that we want something to look back on… in recent years more than ever, I feel. Did it happen, when it doesn’t exist digitally and permanently and is captured in some kind of … “summary of your online-life”? To be honest: I have no real answer to that. It’s more of a philosophical discussion, is it not? Is the fact, that I have done something and contributed to a bigger cause than myself, in itself, not a sufficient reason for doing something? Do I have to look back on it? Do I need to be able to show others what I have done? Is it not better to just live “in the moment”. If so: why did our grand-parents keep photo albums?

Fourth - circling back to the topic at hand

The important point for me in this context is:

  • can we reduce the number of issues
  • can we raise the quality of issues

In the end, any means that makes me and others able to achieve that, would be fine for me (namecalling involved or not).

11

Awesome response! Thank you @TwizzyDizzy ! This is incredibly valuable feedback. I’ve also invited @antgel , another long time community member + contributor who had been blocked by same here for some comment (hopefully he is available). Meanwhile, I think with the above clear statement, we should start actioning the bot immediately (as soon as theo arrives) :+1:

12

I think the idea is it’d be very clear that a contributor closed it. @bot close issue. And the bot would evaluate and then close likely with a comment saying issue closed by {GitHub user}.

I think this is the current state of the effort: https://github.com/RocketChat/Rocket.Chat.GitHub.Bot

I’m guessing just needs ran somewhere and tried out

[edit]

Turns out from the source its slash command inside the issue.

  • /close
  • /label {add,remove} ${label}
  • /open
13

On tuesday I talked to Theo Renck about how to onboard me as a test. As soon as he set it up to include me, we’ll test a bit. :slight_smile:

Cheers
Thomas

14

What’s your experience so far with this @TwizzyDizzy?

15

@aaron.ogle @sing.li

If your in need of extra hands for moderating / cleaning up / managing / supporting the large volume of GitHub issues I’m more than happy to volunteer my time.

I’ve been a active member of the community for 1+ years and have lots of experience managing GitHub repos / Open Source projects.

Had a few dealings with @aaron.ogle and a few other members of the team and would love to lend a hand where possible.

Keen to help out wherever possible. Big time supporter/evangelist of this project and would love to contribute in a way that helps the core devs focus more on the code side and less on the “my stuff’s broken” side

1 Like
16

Forgot to mention. I’m in the Australian time zone which seems to be when everyone else is resting up, can ‘man the fort’ during those off hours when I have free time which I’m sure would be helpful.

17

No worries - just about to join a regular meeting with one of our Australian team member - his Midnight hours :slight_smile:

We are committed to enable this for qualified contributors. @TwizzyDizzy is on the ‘bot’ beta program - and perhaps can expand on his experience.

Please email theo.renck and rodrigo.nascimento for joining the program.

1 Like
18

Well, it’s working as expected. The rest is a function of time, effort and dedication. As of now, I have closed the staggeringly high number of 2 issues and created some issues for the bot in that context.

I plan to do that from time to time and also create more templates for reactions.

That being said, I think it is also very import for a triaging process at Rocket.Chat to make it’s way into daily routine to classify/close the influx of new issues.

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)

It is important to have actions for every kind of situation. After a triaging of new issues, there should be no question left as to what action is to be taken for what issue.

We as community folks can jump in there in obvious cases and for legacy issues (as probably 1000+ of the open issues are) but there has to be a process for new issues.

Cheers
Thomas

19

Thank you @TwizzyDizzy. Very valuable input. Let’s see if we can have someone from our side to look after the issues and roll in @JSzaszvari

20

I love the idea of reaction templates.

So instead of having to have everyone having to maintain a copy of templates simply communicate with bot that its support. It closes and sends the reaction template with details of what to do with support inquiries.

That would be useful for everyone not just contributors

1 Like