GitHub responds to developer demands with new features
GitHub responded with a formal apology and a promise to do better. Yesterday, it rolled out the ability to create templates for GitHub issues and pull requests -- "the first of many improvements" to address those complaints, it says.
With GitHub issues, the method for filing bug reports or feature requests on a project, users can't specify what format either of those things must take. On other platforms, such as Jira, a bug report can be customized so that fields like "steps to reproduce" or "expected behavior" are mandatory.
The current solution involves placing a text file named ISSUE_TEMPLATE in the repository. The contents of that template file are automatically included in the form field used to submit an issue, and can contain anything -- instructions on submitting an issue, a checklist for the submitter to follow, and so on.
Pull requests, too, can use a template file named PULL_REQUEST_TEMPLATE in the same manner.
Unfortunately, this approach doesn't actually enforce the mandatory submission of any particular piece of information, in the manner of Jira. (Custom fields for issues was one of the feature requests.) The data submitted is still just freeform text, although a third-party application or bot could theoretically perform further automated screening on the data.
GitHub has yet to provide a formal voting process for issues, which is another heavily requested feature. Traditionally, GitHub users have voted for or against a given issue, such as a feature request, by posting "+1" in the issue comments. This approach doesn't scale well, since a heavily trafficked project can accumulate hundreds of such "+1s", drowning out any other useful comments along the way.