Live data from Hacker News

Issue and Pull Request templates

github.com

71–80 of 143 posts

Re: Issue and Pull Request templates

#71

Great job! Next item, be able to star issues. That would help a lot and we are able to avoid +1 comments.

I've thought long and hard about the "voting" mechanism, and I am really, really torn. Tons of people writing "+1" is a very aggressive voting mechanism. It is noisy and loud, which I think is a desirable trait for some issues on open source projects. There are lots of projects with awesome developers that listen to their users and are commendable souls. There are also lots of projects with developers that don't give…

But none of that matters for either kind of developer, does it? For the awesome ones it's just noise, and the bad ones will just ignore it.

Why does it matter if it is a simple counter? It'll tell you exactly the same information, with a lot less cluster. And it'll help people reading through issues that are littered with it.

Personally I think having a +1 counter is a win-win solution. And I detest all the +1 comment spam in issue threads, it is noisy and doesn't contribute to the conversation.

Until then, why not create a bot that deletes all +1 posts but edits the main post with a counter of +1s?

Re: Issue and Pull Request templates

#72

> 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.

Re: Issue and Pull Request templates

#74

Earlier quoted context omitted.

Something only belongs in the same branch as the code if it should be forever tied to the same version as the other files in that branch. Suppose I check out a project using a version from a year ago. Project maintainers would certainly not expect me to use last year’s issue template, last year’s preferred pull request layout and last year’s rules for contributing! That is why shoving things into the "git" repository…

GitHub is always going to use the issue template that's on master, not the template from whichever version you happen to have checked out on your machine.

Current file on master to boot. But what makecheck is saying is that only what's in current master matters, not what's in `feature/something-here` or in a commit tree from last year. So shoving it in the repo isn't really a good solution.

Re: Issue and Pull Request templates

#75
post #73
post #46

github released an announcement: https://github.com/blog/2111-issue-and-pull-request-template...

... that's what the HN link is

The original link was to https://github.com/dear-github/dear-github/issues/125

The link was changed to the GitHub blog post sometime in the past hour since _ikke_ commented.

Re: Issue and Pull Request templates

#76
post #65
post #49

Earlier quoted context omitted.

Uhm, yes I would rather not have it in my repo. As to whether or not I want it tracked/versioned, that is completely outside the workflow for versioning in code in a repo. You can maintain a "version" of this separately ala Wikipedia's edit history, or even just have a hidden separate git repo for these things if you must use git. They already have this with gists. With lint configs or npm configs you can argue that…

I totally get where you're coming from. An extra file in your repository is quite the burden. This template file is the straw that broke the camels back. It should be removed. But why stop there? Let's also remove the README.md from the repo. It can also have it's own independent revision history. Maybe they should also add a feature for managing the LICENSE file for you. /sarcasm

Except that CONTRIBUTING.md and README.md and LICENSE are all typical files found in a repo that are independent of GitHub. If I push this repo to bitbucket or gitlab, the same stuff is just as important. But `issue_template.md` and `pull_request_template.md` is only dependent on github and is clutter in the repo. Sure if gitlab or bitbucket have these features and use those names, cool it translates to those services too. But it doesn't matter to the code itself.

Ideally both of those files should be under a `templates` section in the repository settings tab.

Re: Issue and Pull Request templates

#77
post #13

Kinda meh on adding it to the repo since it's yet another file I have to "manage" that isn't really part of the working code.

Living guidelines on how to change the code is an incredibly important part of working code.

I'm going to move this out of wikis and into SCM ASAP.

Re: Issue and Pull Request templates

#78
post #50

So, the issue template is just a default text that individual users can modify, delete, or otherwise disregard?

Would you also like for it to ensure that all check boxes in your template are checked prior to submitting? Ask the user to please submit to a lie detector test? I think this is a completely reasonable solution to the problem and will cover the 99% case.

[deleted]

Re: Issue and Pull Request templates

#79
The problem I have with this is, I don't want a template for the comment a contributor leaves on a PR; I want to display a message to them before they submit a PR. It's not a standard way to display messages, requiring users to read editable text (that has no clickable URLs) and then delete that text after they read it and submit.

Re: Issue and Pull Request templates

#80

Earlier quoted context omitted.

GitHub is always going to use the issue template that's on master, not the template from whichever version you happen to have checked out on your machine.

Current file on master to boot. But what makecheck is saying is that only what's in current master matters, not what's in `feature/something-here` or in a commit tree from last year. So shoving it in the repo isn't really a good solution.

It's the same way with README, CONTRIBUTING, LICENSE, Makefile, package.json, and anything else.
Post reply on HN