111–120 of 143 posts
Why isn't this in a separate branch akin to gh-pages, or a separate repository akin to the wiki data?
>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.
Why isn't this in a separate branch akin to gh-pages, or a separate repository akin to the wiki data?
I think a hidden folder is a decent compromise. >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.
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.
I think it makes sense to have a difference in meaning between "I want to be e-mailed updates about this" (subscribe) versus "I think this is important/valuable/necessary" (star/vote).
Starring instead of subscribing is basically the issues equivalent of "Hire, but not for this team". If you limit it to people who care enough to subscribe, you only get the people who actually are invested in it, and avoid the people who think it should be fixed but who don't actually need it to be.
Earlier quoted context omitted.
I think it makes sense to have a difference in meaning between "I want to be e-mailed updates about this" (subscribe) versus "I think this is important/valuable/necessary" (star/vote).
Devils advocate: if you think it is important, then why don't you want to know when it's fixed? Starring instead of subscribing is basically the issues equivalent of "Hire, but not for this team". If you limit it to people who care enough to subscribe, you only get the people who actually are invested in it, and avoid the people who think it should be fixed but who don't actually need it to be.
- Receive all emails about this bug except comments - Only receive email when this bug is closed
There's also an "this bug affects me", which records that and then gives you the option to subscribe to either of the two options above. Seems like a happy medium.
Earlier quoted context omitted.
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.
This sounds like more 'enterprise' bureaucracy. Coming soon, overly complicated paperwork.
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.
I hope that all repos don't start using it just cause it's there.
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.
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.
I want to know how this works: http://gitmagic.io/