sorawee
2020-10-21 19:18:47

@pocmatos: I just noticed you assigning a PR submitter to a PR (https://github.com/racket/racket/pull/3451). Is this a requirement for your tool to work? My thought is that you can scrape for the PR submitters directly already, and the assignee field is probably best reserved for reviewers.


samth
2020-10-22 02:04:18

I think it can be reasonable if the submitter is the next person with tasks-to-do on the PR


samth
2020-10-22 02:04:28

(I haven’t looked at that one in particular)


pocmatos
2020-10-22 06:04:34

@sorawee That’s a brilliant point… one that I am unsure of. I should probably read through the github docs and see what other projects do but due to lack of time, what I have been doing is make the PR assignee the same as the submitter.


pocmatos
2020-10-22 06:05:23

Github conflates PRs and issues and I think the assignee doesn’t make much sense for PRs, unless you have a special process where the assignee is a third person making sure the submitter stays active and the reviewers do their job.


pocmatos
2020-10-22 06:05:44

For racket and a couple of others, submitter == assignee in my mind.


pocmatos
2020-10-22 06:06:31

After some discussions in Racketcon about triage and process, I was actually going to write a short document proposal so we can have a process for bug triage, assignments, reviewing, etc. However, I haven’t gotten to it yet.


pocmatos
2020-10-22 06:08:29

@sorawee So to conclude, I don’t need the assignee to be anyone really, I just find it that generally if you assign something to a person, that person will feel a (tiny?) bit more pressure to get it done. Ensuring that PR submitters own the PR by assigning it to them, keeps them motivated, while the reviewers don’t need to be assigned because they are already the reviewers. Also, they are generally people who have been in the project for longer and don’t need the extra motivation of being assigned a task in the project.


pocmatos
2020-10-22 06:10:17

I think all issues/prs should have at least a reviewer and at least an assignee to ensure that there’s someone dedicated or with the burden of looking at the issue.


pocmatos
2020-10-22 06:13:29

That assignee might be in the beginning a triage team and the reviewer automatically assigned based on git blame or something of the sort (there’s an action for that). Once the bug is assigned to me (for example), if I feel I am not the right person, I can explain why in the comments and re-assign. I think a process where there’s always someone responsible for a task, ensures the task is smoothly carried out to conclusion. If nobody is assigned, it’s more likely nobody will care. This is why I keep myself assigned to things I think I can solve and want to solve. Every so often I look at all the assigned tasks I have and force myself to fix them before getting on with new stuff. Or if there’s a blockage that stops me to fix it, it forces me to chase those who are blocking it.


pocmatos
2020-10-22 06:16:20

One of the things I promised as an action item to @ryanc is to generate (for those who opt-in) an automatic monthly email listing all the open tasks they are assigned to. I think it’s a great idea. I get to the end of the month and I am reminded of all the balls I have been dropping in the past and forces me (or puts some pressure on me) to pick them up again.