Issue and Pull Request templates

Post by jaywunder » Thu, Feb 18, 2016, 3:13 AM UTC

secstate wrote: post #72

anonicode wrote: post #44

> This is the first of many improvements to Issues and Pull Requests that we're working on based on feedback from the community So there is more to come

Geez. I would hope so. Too bad it took them the better part of half a decade to listen to users. I've already moved a number of my personal projects to Gitlab, Bitbucket or a self-hosted Gogs installation. I've still got reasons to stick with Github for some projects, but it's not the new hotness it used to be. $10 says the next new feature is voting on issues.

Post by slavik81 » Thu, Feb 18, 2016, 4:37 AM UTC

0xffff2 wrote: post #88

pducks32 wrote: post #87

I'd like them to choose a folder name that isn't specific to a site. .github would look silly on hit lab but I like the idea of having a serrated folder.

Trying to use a GitHub only feature on GitLab would look equally silly... This is very much a GitHub specific implementation. It makes sense for it to be identified as such. It would be nice if they used a specific branch a la gh-pages so that everyone's Git repos don't have to be polluted with GitHub specific files.

Post by matheussampaio » Thu, Feb 18, 2016, 5:05 AM UTC

JBiserkov wrote: post #108

dhagz wrote: post #100

Earlier quoted context omitted.

I agree. This gives other git hosting providers the ability to implement the same feature using the same files.

Yes. Yet it's a bit weird in case .github folder is used. Will they support a .bitbucket, .gitlab, etc. They could have used a more generic name like .contributing, but this increases the risk of name collision.

Post by morninj » Thu, Feb 18, 2016, 6:37 AM UTC

alpb wrote: post #122

matthewowen wrote: post #113

Earlier quoted context omitted.

Devils advocate: if you think it is important, then why don't you want to know when it's fixed? Starring instead of subscribing is basically the issues equivalent of "Hire, but not for this team". If you limit it to people who care enough to subscribe, you only get the people who actually are invested in it, and avoid the people who think it should be fixed but who don't actually need it to be.

> why don't you want to know when it's fixed? Knowing when it is fixed/closed is very much different than getting emails about every single comment going on about that issue. Starring issues (as in Google Code Project Hosting) meant "I want to see this getting fixed" and subscribing issues on GitHub does not show anything like that. If I am not mistaken, you only see a list of people “participating” to an issue, you…

Post by tehbeard » Thu, Feb 18, 2016, 7:11 AM UTC

0942v8653 wrote: post #56

anonicode wrote: post #26

Earlier quoted context omitted.

Do you get many issues that don't use your template because people go to /issues and click the new issue button? When I create an issue with a project, I typically don't a link in readme.md.

You could combine it with the new feature and put a warning message into the default box saying to click one of the links in the README in order to get an issue through.