Community help with issue triage

community
1

1.3 is out the door and by all accounts the release has been very well received (45% of you have already upgraded). As some of you may know, we had a lengthy beta period, something we haven’t done for other releases. What we found during the betas is that folks from the community helped out tremendously with testing, creating quality reproductions and participating in discussions around detailed feature design.

We’re planning to formalize an issue triage process that will enable us to keep the issues list in Github organized in a well defined and consistent way. This process would mean working with the issue author to come up with a minimal reproduction that has been confirmed by at least one other person as well as ensuring the issue is labelled correctly and contains enough information for an engineer to begin working on it. The upshot is, nailing down a process will make it possible for anyone in the community to become involved at a deeper level too.

Community help on this will free up core developer time to work on Meteor, it would give community members a way to contribute whilst getting familiar with the Meteor codebase and it will hopefully lead to a neat and tidy Github repo - something we’ve let slide more recently. Practically speaking, this would involve us writing up a crisp process on how to triage issues and make decisions in addition to giving certain Github users write access to the repository. This would be a small but important step towards enabling more active community involvement in Meteor core development.

We’d love to hear:

  1. If you’re interested in helping us with issue triage, please chime in with ideas.
  2. We’re thinking of adopting a policy where we close old issues more aggressively to keep our repo clean and make it easier to spot high priority issues. Our initial thinking is issues that don’t have a confirmed reproduction and include no activity over 30 days would be closed. What do you think about a policy like this?
22 Likes
2
  1. Good idea!
  2. I think that quite a lot of the issues on GitHub could be closed, but there should be some kind of manual checking, or actual issues and good ideas might get lost.
  3. Talking about ideas - issues are being used for feature requests as well. It would be nice to have another platform like uservoice or at least another repo for this.
3

Seems like a good idea :slight_smile: (I would like to help but don’t have the knowledge required about the codebase yet)

  • I also agree in separating issues from feature requests/ideas(previously on Trello if I’m not mistaken).
  • 30 days without activity seems a reasonable timeframe.
  • I think a shared slack channel or whatever between this set of community helpers and MDG could be useful to share/request knowledge about the codebase when needed (It also makes it easier to communicate than submiting thousand of messages through github pinging MDG names)
4

This is a good idea. 30 days seems lengthy for closing old issues. Why not two weeks instead?

We don’t need a Slack channel for this. We could just use these forums in some way.

5

30 days seems like a reasonable start, not too short not too long and I’ve seen other projects pick the same value. This is something we could tweak down the road.

3 Likes
6
7

It would be easier to start at a shorter value and then tweak it to be longer. If we start at 30 days, people will get used to that and it’s unlikely they will ever want shorter. On the flip side, if we start at 14 days, people may end up being okay with it. If they don’t like it, then extend.

8

Like a new category and permissions to create new topics? Still slower than a chat IMO, but could work :slight_smile:

9

The main reason I dislike a Slack channel is because it takes away the openness of the whole thing. Sure anyone can join the Slack channel, but that requires more steps for someone to help out with.

4 Likes
10

Plus, it isn’t as good of a historical record - for example, you can’t post a link to a slack message publicly.

3 Likes
11

Yup, I’d also be interested. I’m still just learning Meteor (almost completed my first app), but seems like a good way to get involved and keep learning as well.

1 Like
12

I thought of using those channels for cooperation between MDG and the people who is helping, not for everyone in the world, and for those cases I believe the sharing button from slack should be just fine (I just tried and I could share a link to a specific message and view the historic data from that channel too).

Anyway, Slack was only a suggestion, I just belive forums and github are too slow compared to something more “streamy”, I’m sure there has to be something that has the best from both worlds :slight_smile:

13

confirmed reproduction = Someone else says they’ve also experienced the error, or there is an OSS repo that someone else has confirmed replicates the error? If the latter, I don’t think it should be an absolute rule, since sometimes there are bugs that are hard to reproduce but are still worth fixing and can be fixed without a repro – for instance with [1] I tried to make a repro and failed, other people were having the problem, and Ben didn’t need a repro to fix.

[1] https://github.com/meteor/meteor/issues/6724

14

Yeah, agreed that for certain issues a short list of steps needed to reproduce it are fine. In regards to issues that have no reproduction but have been seen by multiple people - experience tells me that if these kind of issues have had no activity for over 30 days they are very unlikely to be fixed.

3 Likes
15
16
17

@loren See, but you still managed to write out a helpful and descriptive explanation of the problem and showed that you actually tried something.

The reproduction requirement doesn’t have to be firm, but I think it’s super reasonable to add a can't reproduce label if someone doesn’t include enough details and to close that issue if it’s still that way after 2 weeks, 30 days, whatever (though with as many issues and questions as there are, I think erring on the more aggressive timeline is preferred). If people can’t make a reproduction, it doesn’t seem unreasonable for them to least reach out for suggestions on how they might do that first to the forums and then try again.

Frankly, I don’t feel like an actual Git repo is out of line to ask for. Or steps from a fresh project.

For sporadic issues, reproductions are hard and they need to be documented people can at least relate to them. Perhaps those can slide with a different label for longer. I don’t feel like they are common in Meteor Issues though.

For straight-up questions, unless they are specifically feature-requesting or hinting at feature possibility, I don’t know why to even hear it out. Refer to forums. Close.

I try to check Issues once a day and literally “eep” out-loud at any issue which includes a reproduction repo – often times these can be something I can look into quickly on my spare time. However, most days, I am a silent, eep-less being. Also, @mitar’s contributions usually make me pretty giddy.

Then there’s third-party package issues. I can’t tell if these are on the rise or not. They might be right now because of the 1.3 release but it’s hard to draw the line between “Yo, this package is in serious need of a update” and “Ugh, yea that probably shouldn’t have broke in 1.3, but it did.” – usually it seems like the issue should be in the package’s repo, and not in meteor’s. There should be some sort of policy about these though.

Not sure about Slack. Maybe Apollo project people can speak to it’s effectiveness over there – I haven’t joined it, but I guess it’s being used in a more general-public chat-room sense. Maybe it’d be helpful if there is a community of mods though. I’m generally anti-chat-anything.

I think once things are under control, if core devs can at least keep on top of labeling issues when they might immediately recognize their scope it would allow would-be contributors to at least stick their heads in the right corners. For example, this will allow me to ignore windows swiftly and easily. :grin: (Though I could be persuaded to at least consider looking at those with the correct hopefully-already-documented, super-easy VirtualBox setup guide/instructions from those who are already doing it).

18

Please no Slack. It is really bad for open source development. You loose discussions, cannot link anything, it is really bad for openness. If something, Meteor should use Rocket.Chat for chat. Not Slack. But chat is more for helping people and discussions and so on. If a bug is found, a ticket should be opened.

I am also very in favor of having both bugs and feature requests in same repository/place. Sometimes it is hard to differentiate between them and closing things because “they are not a bug” makes contributions pretty unwelcoming.

In general Meteor as an open source project is pretty unwelcoming to outside contributions. I know that MDG is working on this, but I think we do not need more tools to do that. Just a more open repositories. Just having few extra community people having rights to go through issues, label and categorize them properly, write messages that reproduction is missing and so on. And there can then be a flag that an issue is ready for somebody from MDG too look into (or a community member as well, with a pull request).

But even more than issues, the problem is also pull requests which are not going in.

And tests which are not really working. It is really hard to contribute then. For example, if we talk about new tools, just fix tests. And add some linting and code style checks in the process.

4 Likes
19

Although Slack might not be a good place to open tickets, it would be nice to have a chat room of some kind for discussion and helpful hints.

For example, I’ve worked with Meteor for about 18 months, but am only now starting to assist with issues from time to time. However, I’ve had little success with troubleshooting, as is shown in https://github.com/meteor/meteor/issues/6859.

I would be happy to issue a PR for improving docs, such as the Debugging section for https://github.com/meteor/meteor/tree/devel/tools, but haven’t yet found a series of steps that works consistently yet.

At any rate, having a chat room would be great for these kinds of discussions and might also cut down on issue delays and unnecessary noise.

1 Like
20

@chipcastle There’s a pretty decent chat-room crowd (100+ users, usually) on #meteor on irc.freenode.net. Unfortunately, most of the conversation is about using third party packages, or learning JavaScript instead of conversation that helps contributors or moves the community in a positive direction.