41–50 of 143 posts
Great job! Next item, be able to star issues. That would help a lot and we are able to avoid +1 comments.
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.
Earlier quoted context omitted.
GitHub also supports txt and other common document formats: https://github.com/blog/2061-attach-files-to-comments
Ah, that's a recent addition. Thanks for the pointer. Does it work for bugs? The post mentions pull request comments.
What about attachments to issues? Using gist for it is simply annoying.
Attachments have been around since 2012: https://help.github.com/articles/file-attachments-on-issues-... https://github.com/blog/1347-issue-attachments
So there is more to come
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 this is more of a perception issue. A concerned user will feel like they are adding more weight by "starring" it (or "voting" / "+1"ing it) than "subscribing" to it. Even if they really mean the same thing, ie adding to a counter and notifying on updates. (And I doubt it's a good idea to separate these functions, even if some people will protest they have a corner case where they would want to do one but not…
I'm excited, but the PULL_REQUEST_TEMPLATE.md name is too long for root. What about PULL_REQUESTS.md and REPORT_ISSUES.md?
> 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.
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?
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.