ideas
ideas copied to clipboard
Set expectations for response time
Via https://github.com/probot/probot/issues/11:
Acknowledging contributions in a timely matter and setting expectations for response is one of the most important things you can do to keep a contributor engaged. Based on recent activity, a bot should be able to let contributors know when they can expect to receive a response.
Sounds interesting. I'd like to work on this one.
As per my understanding, the contributor should receive a predicted time when to expect a response and this response can be obtained by a bot who analyzes the recent activities of the repository owner. I hope I got this right?
@AshanthaLahiru I think it's about analyzing the recent activities in the repository rather than the owner, as there are others beside the owner who can review and merge PRs
@Ayush-Rawal, Actually that's what I meant by using owner. Anyone who has push access to repository.
There are services like https://codetriage.com that helps people that want to contribute responding issues. Maybe you could look only to issue activity metric.
Related: http://isitmaintained.com
@evertonfraga Thanks for the link, 'is it maintained' is a nice discovery though I'm unsure how codetriage fits into this, maybe I'm missing something?
Thank you @evertonfraga for sharing it. Checked it out. I think it will be helpful.
I just tried out some implementation part out of curiosity. This is the link of the repo https://github.com/AshanthaLahiru/sert.git . Basically this generates comments once a pull request is detected. Now I'm trying out the part where we have to analyze user’s activity. Am I doing it the correct way?
GitHub
sert - Probot app that set expectations for response time
@AshanthaLahiru as folks use this issue to submit for Google / Rails Girls Summer of Code, please don't yet link to any code until after submissions are done. Sorry for the confusion, we will update the issues to clarify that
@gr2m so can I send you a collab. request to get feedback for that matter? :smile:
I'm afraid we cannot do 1:1 support, we don't have enough time for it. You can work on the implementation and if questions come up of how the bot should work, ask here so everyone can benefit :)
Sure cool, I can understand, I'll do accordingly. Then there's also the slack channel. :)
@gr2m That is my bad. Thank you for mentioning it. Will proceed it that way.
When it comes to analyzing part do we have to only consider the time the person takes to respond to previous pull requests? or do we count all the related activities he does in the repo? As I feel we should take in to account all the activities but it might depend on the person. Could you give me a heads up?
@Ayush-Rawal
maybe I'm missing something?
A given issue can be responded by anyone other than the maintainers. IMO you could account for issues without any kind of response, instead of replies from maintainers only.
The link I sent is a service that puts "random people" to respond issues.
"response time" to me is the time until someone who is contributor of the repository or the organization gets back to an issue. I would not count comments from other people because these could often times be other users confirming that they have the same issue. It also creates an incentive to invite more people as contributors to the organization / repository when they try to help out others, so that their comments start to count for response time, too
@gr2m , I'm sorry i didn't understand it properly. Is this what you meant? when the users comment that they have the same issue we should not count it to calculate the response time, but if they are trying to help with the issue then we should count it to calculate the response time. Correct me if i'm wrong? Thanks in advance.
when the users comment that they have the same issue we should not count it to calculate the response time, but if they are trying to help with the issue then we should count it to calculate the response time.
I would not differentiate based on what the user write, but based on wether the user has been added as contributor to the repository (either directly or via the organization)
@gr2m , Thank you for the clarification. I will proceed accordingly and let you know if there is anything.
What I gathered is, only the contributors comments should be counted. The issue author and other people should not be taken into consideration
@itaditya , That makes sense. Thank you for the input.
Tried little bit of the implementation of analyzing the response time. When taking the response time for a newly created issue what i thought of doing was to calculate the average response time of the initial responses given by the contributors of the repository or the organization to previous issues. Is it the correct way?
Yeah sounds like a good start. I think this bot has lots of room for experimentation, once we have something working, I would install it on a repository and see how it works
That would be great, @gr2m . I'll work on this and let you know when this part is done.
@gr2m , I completed this part.
When taking the response time for a newly created issue what i thought of doing was to calculate the average response time of the initial responses given by the contributors of the repository or the organization to previous issues.
Shall I share the application with you so that you can install it and see how it works with a repository?
sure :)
https://github.com/apps/sert
For testing purpose I have considered the action of contributor creating a issue as well. Thanks in advance. :smile:
GitHub
GitHub is where people build software. More than 27 million people use GitHub to discover, fork, and contribute to over 80 million projects.
can you add some more documentation to it? I don’t know how to test it right now :) Could you invite me to the app’s repository, too?
Sure :smile: , I have sent you an invitation for the repository. You can test the app simply by crating a new issue. Then it will generate a comment giving the expected response time.
@gr2m , any feedback on previous development? :smiley: As my next step I thought of including configuration options which can be used to define what we should take into account when calculating response time. For an example in issues, what should be considered open issues or closed issues or both of them. Is there anything else I'm missing? I would be glad if you can give me some suggestions.