Hacker News Reader

Comment by swang | Hacker News Reader

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.

View on HN

I agree. At least they made a way to separate GitHub stuff:

>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

Many large FOSS projects (which this is aimed for) already have CONTRIBUTING.md etc...

I personally prefer this non UI/Github specific approach.

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.

They can start with `.github` and later give us a way to define a custom name, like adding something on `.gitconfig` or `.gitattributes`.

or like .dotfiles/ or .repoconfig/

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.

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.

Sure you can export issues from Github, easily.

https://api.github.com/repos/rails/rails/issues

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.

With Rust, we already had a mini-template inside of our CONTRIBUTING.md. Doesn't seem very different to me.

Last time I checked the Wiki was a separate, parallel repository, so a precedent exists. I'm not sure where it fits in your classification (code/documentation or project management).

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 changes to those would affect code, which would require them to remain in sync. But what is the point of this new issue_template.md as part of the git repo? It's not as though there will be any significant time where a code change necessitates a change in how issue templates are made.

This feels like a bad hack. Like they saw CONTRIBUTING.md and thought, "well might as well just keep going" and added issue/pr templates.

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.

We plan to support both .github and .gitlab in GitLab https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2864

Were any .md files really a thing before Github? Every pre-GH OSS project I can think of had a simple text file, or sometimes, HTML.

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.

> I mean at this point why is the wiki in it's own space and not git versioned? (Put it in github-wiki folder!)

I understand your overall point, but as a slight aside the wiki is a git repo: https://help.github.com/articles/adding-and-editing-wiki-pag...

If gitlab stored its issues and wiki on a separate branch of the main git repo in some format I can still read when I decide that some other server (github, bitbucket or maybe just plain git), I would actually use those features. Right now they feel like completely unnecessary lock-in, so I’ll stick with Doxygen in-repo bugs/issues/todos and documentation.

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.

Well, you certainly don't have to. If you haven't seen a need for it, no reason to start using it.

I hope that all repos don't start using it just cause it's there.

Reply on news.ycombinator.com