Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Issue and Pull Request templates

github.com

Post reply on HN
Print view View original

61–70 of 143 posts

Re: Issue and Pull Request templates

#61

Post by fapjacks »

jakozaur wrote: post #18

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 a shit about what their users want. Yes, yes, "if you don't like it, write your own", but that simply isn't possible for I'd say most projects out there. And so the +1 comments "voting mechanism" has spawned what I call "the new tyranny of 'locked to contributors'", which itself is a pretty good indicator of the kind of developers running a project. There are projects out there which have issues with huge long chains of +1 comments and enormous bug bounties on BountySource, and for whatever reason, the developers have chosen to ignore the issue, eventually locking discussion to contributors. For me, this is a huge indicator about the developers and the project, and I will generally avoid it if at all possible. The reason I'm on the fence is because it will remove this big, loud indicator when there is a star or vote button or whatever. That is much quieter and easier for the developers to simply ignore -- and of course, that's their prerogative, just as it's mine to not use or contribute to a project for the same reason. Anyways, this is my thought process on the whole voting idea.

Re: Issue and Pull Request templates

#63

Post by sdegutis »

jamesRaybould wrote: post #30
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.

Admittedly we use it on private repos so we haven't seen an issue with it, but there isn't anything from stopping you putting the link in other places

It's not that the link isn't in the right place. It's that regular old users like me are familiar with the Issues -> New Issue workflow, and will continue to go right to that whenever we want to create an issue since it's a guaranteed way to create an issue.

Re: Issue and Pull Request templates

#64

Post by BHSPitMonkey »

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.

But why...

Re: Issue and Pull Request templates

#65

Post by icholy »

swang wrote: post #49
aidenn0 wrote: post #33

Earlier quoted context omitted.

Would you seriously rather have it unversioned and untracked and managed with some random webpage on github?

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

Re: Issue and Pull Request templates

#66

Post by andrewguenther »

tobr wrote: 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.

Re: Issue and Pull Request templates

#67

Post by anonicode »

captn3m0 wrote: post #62
colinodell wrote: post #11

pull_request_template.md also works.

>Issue template filenames are not case sensitive, and can have an extension such as .md or .txt.

colinodell posted that before the blog announcement when we only knew about issue_template.md. It was to point out that you can do this with pull requests as well, not that it was case insensitive.

Re: Issue and Pull Request templates

#68

Post by BHSPitMonkey »

makecheck wrote: post #60
aidenn0 wrote: post #33

Earlier quoted context omitted.

Would you seriously rather have it unversioned and untracked and managed with some random webpage on github?

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.

Re: Issue and Pull Request templates

#69

Post by andrewguenther »

rurban wrote: post #53
sjrd wrote: post #48

Earlier quoted context omitted.

The article says: > If you're worried about the added clutter in the root directory of your project, we also added support for a .github/ folder. You can put CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md files in .github/ and everything will work as expected. So you can put them in `.github/` if you don't want them in root.

I read this, yes. In .github/ people will not see it, and is even more worrysome. It belongs to root, same as CONTRIBUTING.md

Why do people need to see it? It is automatically used when you create a new issue. That's the point.
Post reply on HN