Live data from Hacker News

Issue and Pull Request templates

github.com

81–90 of 143 posts

Re: Issue and Pull Request templates

#81
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

Besides what joshmanders said, I would argue a change in license is usually caused by a change in code and would also mark historically when a project went from X to Y. A README will probably also need to change with new code changes. As for having contributions file. I'm not really for that, but not against it either.

The problem isn't that it's just one file (actually 2 if you're counting pr templates), the problem is we're just going to continually get this pollution of the project because it'll become "acceptable." Slippery slope and what not.

I mean at this point why is the wiki in it's own space and not git versioned? (Put it in github-wiki folder!) Why have separate gh-pages as well? (Just stick them in github-web folder!). Just shovel everything into one git repo. Don't forget the .githubconfig file in case you want to programmatically config a repository instead of going into it's options menu. And on, and on, and on.

Re: Issue and Pull Request templates

#82

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.

Having the templates in the repo at least gives you a degree of portability.

I'm guessing there isn't an "export issues" feature so the above point is moot.

I favour the portability.

Re: Issue and Pull Request templates

#83

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.

Sure, but what if I don't care about being notified of ongoing discussion for an issue, and instead just want to be notified when it's been closed, or maybe a pull-request has been submitted?

Re: Issue and Pull Request templates

#85

Earlier quoted context omitted.

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.

No it's not. I can use the README outside of github as a guide on how to do things with the code. Contributing can define a style guide so we're all on the same page code wise. LICENSE for distribution, Makefile, package.json both are required for the code to work correctly... issue_template.md is only useful in a repo on github.

Re: Issue and Pull Request templates

#86
How does that work with branches ? Is there a master branch required to have this file, what if project doesn't have master branch ?

I think the concept of having a file in source code is flowed for DVCS unless you have so called "source" branch that you can define that is a default source of such information.

Re: Issue and Pull Request templates

#88

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.

Re: Issue and Pull Request templates

#89
post #50

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

Users will find a way to subvert your desires in any case. IMO it's better to let users easily ignore your expectations and set up a bot to automatically close such issues with a comment explaining why. Much better that way than having a bunch of correctly formatted garbage.

Re: Issue and Pull Request templates

#90

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

In which it is demonstrated that absolutely no matter what GitHub does on this topic, someone will complain.

Newsflash: You don't have to use these for your projects if you don't want to.

Post reply on HN