Better Issue Template #7492
Better Issue Template #7492
Conversation
|
Linking to #7476 because it relates and maybe some of those points could be considered re issue template changes before closing this off. e.g. I like the header content you've added, but perhaps linking to external guidelines would allow more comprehensive descriptions of process while keeping the template terse. (see Brackets example) |
|
That could be incorporated into canned responses to close off stale tickets as well. Like: "This issue does not meet reporting standards, please see How to report an issue and update your description. If there's no activity within 7 days this issue will be closed as there's insufficient information to act on." - then set Probot onto them. |
.github/ISSUE_TEMPLATE.md
Outdated
|
|
||
| - Please [search our issues](https://github.com/RocketChat/Rocket.Chat/issues) for an existing issue before opening a new one. This helps us keep all information we need to fix the issue in one place. | ||
|
|
||
| - Before reporting a bug, please try reproducing your issue against the latest version of Rocket.Chat and don't forget to include any errors on your console (browser and server). |
There was a problem hiding this comment.
Might include a link to this so those unfamiliar can figure out how to get logs: https://rocket.chat/docs/contributing/reporting-issues#gathering-logs
|
I totally agree with those issue guidelines. Github is neither for asking questions nor for telling people how to properly reproduce an issue or how to debug things.
I like this idea a lot. I would maybe increase the time to 14 days (maybe warn after 7 days, close because of inactivity after 14 days, if that's possible) but in general, I think, this is the way to go :) Maybe one could also add a link to https://demo.rocket.chat/channel/support for support. What do you think about one further question like:
Not quite sure about this, but it may force people to really think about their issue. Cheers |
and fix some line breaks and heading
|
Just occurred to me.. we have all of those markdown links... but when it is injected into the issue those aren't going to be clickable.. They will show up in raw form. |
|
@geekgonecrazy I normally open the issue preview when i need to read issues templates. But I agree with you. Any suggestions? |
|
@MartinSchoeler @geekgonecrazy How about giving a checklist. Like, Guy would check if he has searched for duplicates, on stackoverflow & more checks. |
|
@MartinSchoeler @pkgodara @geekgonecrazy - I like the idea of checklists but think that and the problem with markdown and links in the template should be solved by having a MD file about reporting issues (again, like Brackets) and just linking to that from the template. This would keep the template content more manageable and focused. |
|
I do like how brackets does it.. but I have to wonder how many people actually bother to read a linked doc? I can honestly say I've ignored multiple. Not because I don't care about their guidelines. But because I'm trying to get the bug reported quickly and get back to something else. I don't think expecting someone to leave the issue, read a guide and then come back is going to help. :( The easiest to do are those that give a couple of lines and then ask some guestions. If during the questionnaire it gives me a link to help gathering the info... At that point I'll usually follow it. Because I am after all trying to help them get info needed to fix it |
|
The target group I'm thinking of re guidelines, would not be you or I, but more the kind of user who has little background contributing or working with open source, which I think is where the bulk of low-quality issues are coming from. People who are treating issues like a support ticket, or who are genuinely wanting to make quality contributions but need some help understanding the basic principles of github issues and giving feedback on open source projects, that we all take for granted. Either way, I think the template should be simple and form-like, not the place for informative content cluttering the header of every issue. The guidelines doc was a way I thought the more informative content could be kept out of the way for those that do really need it. |
|
Just to be clear for @MartinSchoeler, I'm not part of the core team and my feedback shouldn't be considered a blocker to resolving the issue, I'm just offering another perspective. |
Agreed. The aim of issue templates is to make an issue of such high quality, that you ideally can solve it without any further question (I know, happens seldomly, that's why I said "ideally"). Any question, any asking for logs or what not increases the time for an issue to be solved, makes the issue longer to read , which is bad for somebody searching for duplicate issues and only reading 10 comments, while the thing that makes this issue identical to his is in comment 11.
It might not. But it gives you a justification to reject an issue because of its low quality. I know. You said in some other issue that you find that rude, but to be honest: As @timkinnane said: This issue tracker is no support forum or paid support. Somebody not willing to provide sufficient information to get a grasp of his issue wants others to do work for him... as simple as that. And I don't think one should support that. Just my two cents... Cheers |
|
Opened a PR on our docs repo: RocketChat/docs-old#330 Also working on potentially shortening this down: https://hackmd.io/OwNghgxgTAJlUFoDMwYA4EBYBGZFnETTTzAEYpsAGJGYIA== Thoughts? |
|
At the point "This issue tracker is no support forum ..." I'd like to link to #6578 . If issues are not the room for support questions, but only bug report, where does user discussion happen? On demo.rocket.chat? I have given it up there. May be that's one reason for a lot open issues, which are not bugs/issues in the classic way. |
|
@localguru I, too, definately see a need for some place to discuss topics/questions/issues before they become real issues in a bugtracker-sense. Github may not be the right place, though my first thought was indeed #support on demo.rocket.chat. Don't know if a mailing list is the right thing for a target audience of people who like web-chats. |
|
@TwizzyDizzy a mailinglist is a little old school, that's right. But I like email ;) I think the support forum is good "tool", but time-delayed discussion like here on github or via email is not possible. |
|
I like email, too. But that's just us ;) @ time delay: true. So maybe this would be something: https://www.discourse.org/ (demo forum: https://try.discourse.org/) It's open source and could be hosted at discourse.rocket.chat. Even github-based login is possible. |
|
@localguru @TwizzyDizzy I dont think that another tool can resolve the problems from the #support channel on demo.rocket.chat. We just need more guys that doing some support - or the whole community has to exchange the experience setting up things. Maybe it is better to suggest the "non-knowledge zero deploy" as describing the entire infrastructure and helping the user just for this one time - but he couldnt help himself on other issues. And this is absolutely okay, not all of the users of rocket.chat can be very experienced with this webserver / reverse proxy / websocket / docker stuff. You know what i mean? |
|
@TheReal1604 With all due respect: I strongly disagree.
Why? So far we have established the following things:
And with what tool would they exchange that experience? Documentation and/or another platform. In general, you have more people needing support than you have people being able to give support. So you need to document solutions for people in order to help themselves.
I must object heavily. It may be me or my old-fashioned views (well, I'm 31, so not THAT old) but I'll state it as atomic as I can: if you don't know this stuff above, then you simply shouldn't run a service on the open internet. Period. And even if somebody runs a software in an intranet and fucks up, he might still harm users in this intranet with his server being configured improperly (and everything that may result from that). One might discuss the quality of documentation (which, in general, I think is quite good for Rocket.Chat) but to make everything fool proof? I don't think so. Oh, and @geekgonecrazy: to come back topic... I would change the order to
... (seems to me to be a more chronological progression when I want to know what somebody's problem is) but apart from that, I think that should do the trick :) Cheers |
Sry, maybe I wrote this a bit misunderstanding. This is also my opinion. I mean with "zero-knowledge-deployment" something like: https://rocket.chat/hosting
All other issues like apache2 load balancer issues is not related to RC.
The quality of the documentation must be improved. In the last months the documentation got better, Sry, i dont want to disturb. Just sayin that you can not resolve an social / community / documentation issue with something technical. Maybe its worth a try with discourse. |
|
Hey guys, just to leave my 2 cents here as well, since this conversation has been happening in our office as well:
It has it's pros and cons, we can help people with problems solve them right away (if we do have enough people to answer questions), however it might get repetitive for people to answer the same questions again and again, so what we could do is get the answers and compile them in the docs somewhere (FAQ or something) for easier access in the future.
The docs are getting a great focus on the close future, we have people working on it to make it as accessible and easy to use as possible. I just want to try and move this discussion to an issue instead of this Pull Request, I really appreciate the discussion we created here but this PR is focused on the issue template itself instead of the overall 'how to solve the support problems' we derailed into. |
|
Updated based on feedback. Depends on this PR: RocketChat/docs-old#330 Regarding the level of support on the community server. I think if we had more community members there it would help a lot. I think also we may need to break it up a bit. Maybe separate out deployment support, much like we do already with #ubuntu-snap. Like @gdelavald mentioned documentation is getting a lot of attention and will be getting better. We have a bot to help linking to docs. An FAQ also I think will be useful. I think for a first iteration this will be a good start. We can continue to improve on the linked doc. |
|
opened an issue with parts of the new template #7532 |
@RocketChat/core