Ansible has grown rapidly over time and has benefitted greatly from all the collaborators and contributors on github.
One slight disadvantage to Ansible’s success is the volume of tickets created each day in the ticketing queue. We find ourselves spending a lot of time asking for the basic data we need to help solve bug reports or to understand what a pull request offers.
In more “enterprisey” bug trackers, there are many many fields a user has to fill out when creating a ticket. Usually the end users are discouraged by the number of fields and will simply stop filling them out or even making tickets. However, these fields help project managers and other contributors group issues into buckets to work smarter on solving lots of tickets at once. Constantly context switching between issues of different types is difficult for people like myself.
Our solution is to bring a little bit more “enterprise” to the github issue tracker without slowing down issue creation for the users. We have built a robot that will examine all new issues and verify the description matches a simple markdown template.
If the description does not contain the headers in the template, a warning will be added to the comments. If the description is not corrected within 7 days, the issue will be closed.
Ansibot is now running and some of you may have already noticed comments in your issues.
The messaging, features and algorithms behind this bot will no doubt evolve over time and we will do everything we can to make the bot helpful rather than annoying.
So "we cannot handle the number of contributions" is met with a "we will just make it harder for people to contribute".
This is silly, I send in a pull-request for an obvious bug in the uri module, and now I am asked to fill out a template or my pull-request will be closed in 7 days.
So GitHub is quite useful to us, but we have to ask a lot for ansible
versions and steps.
This allows us to move faster and get more done and will also help us
auto categorize tickets.
I'd encourage you to give it a chance, it is only implemented on new
tickets and will allow us to move much faster in just testing code vs
asking repeated questions every day which is necessary with the level
of interest in this project.
If we moved to bugzilla you would still have the template without the
single sign on and pull request integration, which I love Github for.
I think you misunderstood. I opened a *pull-request* for a one-line patch and am asked to fill out the template. Regardless of the details in my commit message. That is crazy. (Please look at the link I send you...)
Do you expect us to use a template for commit messages in pull-requests ?
Besides, have you looked with the Github people to see whether they could add a custom (template) text to the issue input form ?
Seems to me that is what you (and pretty much every other project) needs, rather than have a bot comment on opened issues after the fact...
Actually, I disabled the bot on pull requests earlier this afternoon. We will be deciding on a different process to follow for those in the coming days.
I definitely do take offense at the implication we’re trying to make it harder to contribute on purpose, which has never been the case.
You could have asked if we could make this template optional, for instance, rather than taking an accusatory tone.
“Besides, have you looked with the Github people to see whether they could add a custom (template) text to the issue input form ?”
Actually we have, numerous times. We’ve asked GitHub for lots of bug tracker improvements. We haven’t really seen them happen, but we can’t really hold this against GitHub either – we’re a small fish in a big pond. We do note that recently we can categorize issues from the issue description page – which I’m not sure if that came from one of the twenty or so bugs we’ve filed on the GitHub issue tracker, but we can hope Let’s do say we give lots of feedback, but we’re also quite committed to keeping everything on GitHub. Simply put, the quickest solution was to implement something ourselves.
We do need a different template for pull requests – but the categorization of whether something is a bugfix, feature, or docs pull request is something we will want to be asking via the bot.
Not all questions are appropriate, but we still need to ask a few more – as often people will just submit code without explanation, so there will definitely be a small template.
My example shows you do (or at least you did). I am not implying anything, my one-line patch will be discarded unless I fill out a template. How does it not make things harder ?
I understand why it is useful for bug-reports, I simply think this particular implementation makes the situation worse. People will file a bug, chances are low they know/use the template, are being requested to rephrase even when they provided all information already...
If you think this is fine, the thread ends here for me.
My example shows you do (or at least you did). I am not implying
anything, my one-line patch will be discarded unless I fill out a
template. How does it not make things harder ?
Dag, by my reading of the responses, the template prompt as it was on pull requests was a unintended side effect of having the template prompt for issues. It's an easy mistake to make as Github treats PRs as issues internally so without careful use of the API it's easy to hit both by mistake.
The replies have also stated that they have fixed that and will do something else for pull requests.
They've also stated that the attempt isn't geared at making things harder, it's geared at making things overall better, by auto-prompting for the information that would be required anyway, and providing a way to pre-supply that information in a desired format.
Please don't assume malice.
I understand why it is useful for bug-reports, I simply think this
particular implementation makes the situation worse. People will file a
bug, chances are low they know/use the template, are being requested to
rephrase even when they provided all information already...
If you think this is fine, the thread ends here for me.
I never assumed malice, not sure why you are getting back to that theme.
Fact is that it didn't work well, and that's what I reported (even for issues). Fine for me if this is intended.
And if you like me to sugarcoat stuff like this in the future (as it seems that's what this is about mostly) let me know what phrases you like me to use for sugarcoating. A template will do just fine
Thanks James. As discussed on IRC on Tuesday I send a feature-request to one of the Github people I worked with when improving the Email service hook a few years ago. The feature is to have a custom text (i.e. your template) to be pre-filled in the issue-tracker 'New issue' text-form.
It got forwarded to the team responsible for the issue-tracker, and the feature was promoted into their Feature Request List. Contrary to service hooks, you cannot send in patches to this part of Github :-/
