2018-01-12 15:24 GMT-08:00 Smith, Barry F. <[email protected]>: > > > > On Jan 12, 2018, at 4:32 PM, Patrick Sanan <[email protected]> > wrote: > > > > > > > > 2018-01-11 22:36 GMT-08:00 Smith, Barry F. <[email protected]>: > > > > > > > On Jan 11, 2018, at 11:40 AM, Patrick Sanan <[email protected]> > wrote: > > > > > > One idea is to impose a stricter guideline that things on the > bitbucket PR page are things that everyone is actively trying to merge. > That way, maintainers can just look at the bottom of the list to see what's > lagging, instead of having to to work up the list and try to remember which > of the PRs are WIP or proposals or experiments or even abandoned ideas. > > > > Very valid point. Perhaps we could have some way to convert the > "proposals" to Issues so they are not lost but no longer clog the pull > requests. Or the originator of the pull request (i.e. Jed) could kindly > remove the pull request by converting it to some other archival form. Or at > least label the pull request as Archival as opposed to active. > > > > Any reason to not just create/select an issue, assign it to someone, and > include the relevant branch name in the issue description? > > Hmm, now there are two things to keep track of for each pull request > (the pull request web page and the issue web page) so you've doubled the > pain just so you can use the bitbucket issue assigner to know who is > assigned to it. > I meant to suggest to do this only for "not actively trying to merge" PRs that you want to take off the PR page and convert to issues.
> > Put you have a very valid point. We do need to assign each pull > request to someone. We could simply leave at the first comment on the pull > request the assigned. For example @barrysmith you are assigned this pull > request. Then that person turns on watching for the request. > I think this was actually Matt's point, but seems reasonable to me as well : ) > > Barry > > > Barry > > > > > > > > This probably requires an itchier trigger finger on declining PRs > which need substantial work. > > > > > > A related point is that (as happened with the last PR I made), if a > big edit is performed after the original PR is made or even approved, then > it's not always clear "whose court" the PR is in. Maybe it's better to just > make a new PR in this situation. I'm not sure if bitbucket allows you to > decline your own PR (I fear not) - that would make this easier. > > > > > > 2018-01-11 9:00 GMT-08:00 Smith, Barry F. <[email protected]>: > > > > > > what do people suggest to improve it. > > > > > > We can't have valuable pieces of code going stale in there for > months. > > > > > > > > > > > > > > >
