一些子仓库维护自己的问题跟踪器，因此在子仓库上进行一般的问题管理任务是有用的。我已经将这些任务缩小到：
kiayqfof1#
https://golang.org/cl/233377提到了这个问题：cmd/gopherbot: extend gopherbot's general tasks to all subrepos
cmd/gopherbot: extend gopherbot's general tasks to all subrepos
lmyy7pcs2#
总体方向对我来说似乎是合理的。我们需要关注所有问题追踪器和将会产生追溯影响的问题。我认为最好在这里逐步推出任何更改，以避免喧闹的人群问题，并使审查正在修改的内容变得更容易。你是否同意首先为vscode-go问题追踪器推出这个功能，然后再处理其他仓库？由于你和@hyangah是其所有者，因此在该仓库上取得进展应该更容易(并且让你判断gopherbot是否在帮助而不是制造混乱)。/cc @golang/osp-team
apeeds0o3#
这有道理。我在CL中做了这个调整。
bt1cpqcv4#
https://golang.org/cl/234023提到了这个问题：cmd/gopherbot: print referenced repo in closeCherryPickIssues
cmd/gopherbot: print referenced repo in closeCherryPickIssues
xzlaal3s5#
https://golang.org/cl/308790提到了这个问题：cmd/gopherbot: add more deleted issues to deletedIssues map
cmd/gopherbot: add more deleted issues to deletedIssues map
5条答案
按热度按时间kiayqfof1#
https://golang.org/cl/233377提到了这个问题：
cmd/gopherbot: extend gopherbot's general tasks to all subreposlmyy7pcs2#
总体方向对我来说似乎是合理的。我们需要关注所有问题追踪器和将会产生追溯影响的问题。我认为最好在这里逐步推出任何更改，以避免喧闹的人群问题，并使审查正在修改的内容变得更容易。
你是否同意首先为vscode-go问题追踪器推出这个功能，然后再处理其他仓库？由于你和@hyangah是其所有者，因此在该仓库上取得进展应该更容易(并且让你判断gopherbot是否在帮助而不是制造混乱)。
/cc @golang/osp-team
apeeds0o3#
这有道理。我在CL中做了这个调整。
bt1cpqcv4#
https://golang.org/cl/234023提到了这个问题：
cmd/gopherbot: print referenced repo in closeCherryPickIssuesxzlaal3s5#
https://golang.org/cl/308790提到了这个问题：
cmd/gopherbot: add more deleted issues to deletedIssues map