search

Automattic / mongoose

MongoDB object modeling designed to work in an asynchronous environment.
https://mongoosejs.com
MIT License
27k stars 3.85k forks source link

Too Many Issues with Mongoose #5636

Closed heisian closed 7 years ago

heisian commented 7 years ago

Do you want to request a feature or report a bug? Feature

What is the current behavior? Issues are opened without following format or posting reproduction scripts. Issues also contain support items that are best served elsewhere, like StackOverflow, forums, or chat, where documentation and proper usage can be referenced.

If the current behavior is a bug, please provide the steps to reproduce.

  1. I am a young Mongoose user.
  2. I do not know how to do something in Mongoose or am unaware about its functionality.
  3. I need support and therefore post an "issue" on this repo.
  4. My request is neither a feature nor a bug, yet I still need help from the community!

What is the expected behavior? I should really post on StackOverflow or some other channel (suggest opening a Slack channel?) for usage/documentation help.

For contributors, suggest adding in a **Repro script here (or something)** section instructing the user to post a detailed repro script for bugs, and a PR for features, respectively. If not provided, the issue should be closed until the poster can provide enough information to warrant the issue.

Please mention your node.js, mongoose and MongoDB version. node v8.1.4, mongoose v4.11.9, MongoDB v3.4.7

nosnaj commented 7 years ago

To add to this, I think issues should have an expiry date of 6 months or something realistic like that. The oldest open issue is 5 years old...

vkarpov15 commented 7 years ago

Regarding issues without repro scripts, actionable details, etc. we have a GitHub format for that. In order to be friendly to beginners we try to nudge them into providing more information and mark the issue with 'Needs Clarification', and then close those out if there's no response after a certain period of time. We already have a slack channel.

As for issues that have been open for a long time, sometimes there's a good idea that we just haven't prioritized yet, so we keep it open. The oldest currently open issue AFAIK is #1102 and its a worthwhile task, just other issues have been higher priority.

heisian commented 7 years ago

I'm hoping to promote a more aggressive stance on closing issues.. just glancing at the front page alone more than 50% of the "issues" are not to do with mongoose but those seeking help with JS usage in general.

For example: https://github.com/Automattic/mongoose/issues/5651

The above is a user who needs help with what really is JS syntax and would probably get more support looking in stack overflow rather than posting here and leaving an open "issue".

Allowing such things to stand does two things:

  1. Pollutes the mongoose issue space and distracts contributors from real issues.
  2. Prevents the user from actually getting the type of help they need, or being more proactive in finding an appropriate avenue for their solution.

I would highly suggest just closing the "needs clarification" and "repo script needed" issues until the OPs actually respond. Otherwise you're just left with a bunch of open issues that don't contribute to the repo.

vkarpov15 commented 7 years ago

I agree with point (1), but by virtue of milestones we don't really look at needs clarification / can't reproduce issues, we just go through and batch close them when convenient. Do you mean it distracts potential contributors from finding issues to work on?

"Repro script needed" is a different label because we use it to mean we think we have enough info to reproduce the issue, we just need to take the time to try to reproduce it.

heisian commented 7 years ago

well a pile of issues is inevitable in any open source repo it seems, but yes any sort of clutter both on the contributor side and the consumer side i think distracts from the repo as a whole.. I would even put the burden of proof for "repro script needed" on the O.P.

I would also guess that you don't have all day to work on this project and have other commitments, and in my view reducing the amount of extraneous items from a scope of work can contribute in small amounts to better focus, better code quality, better support, happier users

vkarpov15 commented 7 years ago

That's a very fair concern. There's a fine balance between listening to users and making it easy for them to report bugs even if they can't create a clean repro script, versus simply closing everything that doesn't follow the issue template exactly. We tend to err on the side of the former right now but we're considering some changes to streamline things. Do you have an example of a project that you think handles this well?

heisian commented 7 years ago

Yes, the very popular Laravel framework handles issues quite well.

They are a bit extreme I think, bordering on rude - but they have tons of users and a very active community and so need to be pretty heavy-handed.

https://github.com/laravel/laravel (generalized framework) https://github.com/laravel/framework (core, which the above depends on)

Issues and feature requests are religiously scrutinized by contributors and they have a policy of closing more issues than not (9,313 closed vs. 106 open).

I definitely understand wanting to keep good support for users and you do a really good job of helping users out who need the help. BTW, how can I join the slack channel? thanks!

vkarpov15 commented 7 years ago

http://slack.mongoosejs.io/ is how you get on the slack channel. Does laravel have some policy docs on what issues they close vs which ones they don't I can read?

heisian commented 7 years ago

I think quickly reading a few of the threads can give a good idea of how they handle things... such as:

https://github.com/laravel/framework/issues/21506 https://github.com/laravel/framework/issues/21498 https://github.com/laravel/framework/issues/21451

vkarpov15 commented 7 years ago

Hmm that's fair, I suppose having forums or just pointing people to stack overflow can be a way to ensure that issues is only for bug reports. I'm just wary because I don't check stack overflow often, and its helpful for me to see if a lot of people are having the same issue with the API.

heisian commented 7 years ago

I did find it a bit hard to join the mongoose slack channel.. having forums or a join-as-you'd like slack channel (instead of invite-only) might help.

For me, the more green I was the more time I spent on stack overflow :P I think the social aspect of that board can really help mongoose users connect the dots

vkarpov15 commented 7 years ago

I'm pretty sure you can't have a join as you like slack channel, which is why we have http://slack.mongoosejs.io/ to send you an invite when you enter in your email... Any recommendations for which forums OSS projects should use?

heisian commented 7 years ago

hmm this might be a good alternative to having to start/host mongoose's own forum:

https://stackoverflow.com/questions/tagged/mongoose

heisian commented 7 years ago

Looks like we've already got some folks writing their own collaborative guides:

https://stackoverflow.com/documentation/mongoose/1168/getting-started-with-mongoose#t=201710031945352704886

might as well bolster that community

vkarpov15 commented 7 years ago

Good idea. Perhaps I can start contributing on stack overflow and hopefully reduce the amount of help requests that come in here.