GitHub serves up the first of many promised improvements to address long-unaddressed user feature requests Weeks ago, developers took to GitHub to voice their dismay at the way the code hosting platform was ignoring long-standing feature requests. 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 any detail — 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 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. Development ToolsSoftware Development