Set expectations for response time about ideas HOT 39 OPEN

@nikramakrishnan hello Nikhil, welcome to Probot 👋

I can see that most of these projects have already been built to some level by students. Isn't the coding part supposed to start after the selection process?

Yes. We ask students not to share their work on the ideas labeled with summer-of-code. But we encourage discussion and if people already want to work on them that’s fine with us, as long as they don’t share their code

What will they be doing during the summer?

There are many more ideas :) We expect the GSoC students to work full time on Probot for the time. If they apply with a project that they already finish by then (or someone else did and there is no longer a point in working on it) we will find a different project idea together with the student

Also, do the students who have almost completed/in the process of working on an issue have an advantage over newcomers? Is it possible for me to submit a proposal, and start working on current issues so that my proposal will be considered?

Yes, but we look into all kinds of contributions. Having a Probot app built (or several) is great! Helping out with open issues / pull requests on the Probot codebase is great. But also answering questions in issues or on slack is equally important

Hope that helps?

from ideas.

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?

from ideas.

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

from ideas.

"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

from ideas.

What I gathered is, only the contributors comments should be counted. The issue author and other people should not be taken into consideration

from ideas.

@AshanthaLahiru I think it would also be interesting to think about using the median to calculate the expectation of response, since the average can be affected by very high or very low values ​​and perhaps the median best describes the expectation of actual response, so it may be interesting to do an exploratory data analysis(EDA) on data from some GitHub repositories to better understand its characteristics.

from ideas.

@Ayush-Rawal, Actually that's what I meant by using owner. Anyone who has push access to repository.

from ideas.

@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

from ideas.

Sure cool, I can understand, I'll do accordingly. Then there's also the slack channel. :)

from ideas.

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)

from ideas.

@gr2m , Thank you for the clarification. I will proceed accordingly and let you know if there is anything.

from ideas.

@itaditya , That makes sense. Thank you for the input.

from ideas.

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

from ideas.

That would be great, @gr2m . I'll work on this and let you know when this part is done.

from ideas.

@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?

from ideas.

sure :)

from ideas.

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?

from ideas.

Sure 😄 , 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.

from ideas.

Do you have it installed on a test repository where we could give it a try without installing? It didn’t work on my own test repo but I guess that’s a feature, as I’m the maintainer myself not an outside contributor? gr2m/sandbox#33

from ideas.

@AshanthaLahiru oh wait it worked now :) The "1 minutes" is rather optimistic though :D maybe this is not the best repository to test it on though

I would suggest to change the wording. Instead of saying "someone will get back to you within x minutes" I’d say something like "based on past issues, someone will get back to you within x minutes"

from ideas.

@gr2m if we send the proposal in this issue will it still be considered? Thanks in advance.

from ideas.

Yes

from ideas.

Thanks @davilaerte . I'll look into that. 👍

from ideas.

Sounds interesting. I'd like to work on this one.

from ideas.

@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

from ideas.

@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?

from ideas.

Thank you @evertonfraga for sharing it. Checked it out. I think it will be helpful.

from ideas.

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

AshanthaLahiru/sert

sert - Probot app that set expectations for response time

from ideas.

@gr2m so can I send you a collab. request to get feedback for that matter? 😄

from ideas.

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 :)

from ideas.

@gr2m That is my bad. Thank you for mentioning it. Will proceed it that way.

from ideas.

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?

from ideas.

@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.

from ideas.

@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.

from ideas.

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?

from ideas.

https://github.com/apps/sert

For testing purpose I have considered the action of contributor creating a issue as well.
Thanks in advance. 😄

GitHub

Build software better, together

GitHub is where people build software. More than 27 million people use GitHub to discover, fork, and contribute to over 80 million projects.

from ideas.

@gr2m , any feedback on previous development? 😃 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.

from ideas.

Cool :D, Yes @gr2m , I think that is because of the bot only consider the responded issues to calculate response time. In this case all the responded issues are commented by a contributor at the same time. 😄

Noted, I will change the message accordingly.

You can check in this repo.
https://github.com/AshanthaLahiru/Blog/issues

GitHub

AshanthaLahiru/Blog

Contribute to Blog development by creating an account on GitHub.

from ideas.

Hi, I am really interested in some of these projects and I would really like to apply for one of them for GSoC. I can see that most of these projects have already been built to some level by students. Isn't the coding part supposed to start after the selection process?
What will they be doing during the summer? Also, do the students who have almost completed/in the process of working on an issue have an advantage over newcomers? Is it possible for me to submit a proposal, and start working on current issues so that my proposal will be considered?

from ideas.