Live data from Hacker News

Issue and Pull Request templates

github.com

51–60 of 143 posts

Re: Issue and Pull Request templates

#53
post #48
post #47

I'm excited, but the PULL_REQUEST_TEMPLATE.md name is too long for root. What about PULL_REQUESTS.md and REPORT_ISSUES.md?

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

Re: Issue and Pull Request templates

#54

This sounds like more 'enterprise' bureaucracy. Coming soon, overly complicated paperwork.

If you've ever managed a big OSS project you'd not think of it like 'enterprise' bureaucracy but a time safer. If OSS users can't even be asked to fill out a minimum amount of information based on a template, then I have zero interest spending my free time helping out.

Re: Issue and Pull Request templates

#55
post #53
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

What's the use case of people seeing it? GitHub should be adding it automatically; issue reporters aren't copying-and-pasting the template manually. The only people who should really need to see the file itself are maintainers (or fork maintainers), unless I'm missing some use case.

Re: Issue and Pull Request templates

#56

There is already a way of doing this using the URL like: https://github.com/jamesRaybould/go-mssqldb/issues/new?body=... You can then add it as a simple href to the readme.md. It also means that you can have multiple templates depending on what a user wants to do, just by having multiple links and changing the content of the `body` parameter. Simplest way to get going on this is to use http://urldecode.org to write t…

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.

Re: Issue and Pull Request templates

#58

Earlier quoted context omitted.

Doesn't this inadvertently give users access to something they might not otherwise have? That is, the ability to add labels on issues. Might not really be a security concern, but not really desirable behaviour either.

I don't think so, it seems like its just a link to what you can see within the UI anyway and simply pre selects it for you. But I am by no means an expert on it and it is pretty simple to experiment with if you want to give it a try

People who aren't owners can't normally add labels.

Re: Issue and Pull Request templates

#59

Earlier quoted context omitted.

Seems like this one is solved by showing the number of subscribers to an issue. I don't think this really needs to be a separate feature.

Yes. When you subscribe to an issue you show that you are at least interested enough to receive notifications about it.

Eh, I don't like getting spammed with notifications when I'm subscribed to a popular issue. Maybe that will be less of a problem with fewer people posting +1 comments, but still. I wish I could just get a notification when the issue is closed.

Re: Issue and Pull Request templates

#60
post #33
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.

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 is a hack.

Having this stuff under some revision control is useful but it could be a separate, parallel repository. Frankly, I think everything for project management should be in one repository, and everything for code and documentation should be in another, and GitHub should be able to use files from both to present a project site.

Post reply on HN