Only apache/beam-site has migrated to using gitbox, I'm not sure why apache/beam has not yet.
On Thu, Aug 31, 2017 at 5:49 PM, Thomas Weise <t...@apache.org> wrote: > Is the project using gitbox? If so, there should be a close button if you > have linked your ASF id with your github ID and then complete the gitbox > account linking here: > > https://gitbox.apache.org/setup/ > > Thanks, > Thomas > > > > On Thu, Aug 31, 2017 at 5:01 PM, Ahmet Altay <al...@google.com.invalid> > wrote: > > > I do not think there is a close button. It is possible to close a PR by > > pushing a commit with a message like "closes #1464". Does anybody know a > > better mechanism? Perhaps we could have a closebot :) > > > > Also, I prepared a PR for the website to capture this policy ( > > https://github.com/apache/beam-site/pull/309). > > > > Ahmet > > > > On Thu, Aug 31, 2017 at 2:50 PM, Eugene Kirpichov < > > kirpic...@google.com.invalid> wrote: > > > > > Policy sounds good to me. Which members have the right to close a stale > > PR? > > > E.g. I'm a committer and I'd like to close > > > https://github.com/apache/beam/pull/1464 but I don't see a close > button. > > > > > > On Sun, Aug 20, 2017 at 4:35 PM María García Herrero > > > <mari...@google.com.invalid> wrote: > > > > > > > Thanks, Ahmet, for bringing this up. > > > > > > > > Here's what PBS professional does, which sounds reasonable to me: > > > > "the maintainers will mark any pull request that has had no activity > > for > > > > two weeks with an *inactive* label. Any pull request that's been > > inactive > > > > for three months will be closed, if the maintainers cannot reach the > > > > owner. No warning will be issued; it's up to you to keep track of > your > > > > pull requests." > > > > > > > > https://pbspro.atlassian.net/wiki/spaces/DG/pages/50397500/ > > > Inactive+Pull+Requests+Closed > > > > > > > > María > > > > > > > > On Fri, Aug 18, 2017 at 5:18 PM, Ted Yu <yuzhih...@gmail.com> wrote: > > > > > > > > > bq. component leads regularly triage their components, including > > > > > unassigning issues. > > > > > > > > > > +1 > > > > > > > > > > On Fri, Aug 18, 2017 at 5:11 PM, Ahmet Altay > > <al...@google.com.invalid > > > > > > > > > wrote: > > > > > > > > > > > To summarize the stale PR issue, do we agree on the following > > > > statement: > > > > > > > > > > > > A PR becomes stale after its author fails to respond to > actionable > > > > > comments > > > > > > for 60 days. The community will close stale PRs. Author is > welcome > > to > > > > > > reopen the same PR again in the future. The associated JIRAs will > > be > > > > > > unassigned from the author but will stay open. > > > > > > > > > > > > On Wed, Aug 16, 2017 at 3:25 PM, Ted Yu <yuzhih...@gmail.com> > > wrote: > > > > > > > > > > > > > bq. IRAs should still stay open but should become unassigned > > > > > > > > > > > > > > The above would need admin privilege, right ? > > > > > > > Is there automated way to do it ? > > > > > > > > > > > > > > bq. Prevent contributors/committers from taking more than 'n' > > JIRAs > > > > at > > > > > > the > > > > > > > same time > > > > > > > > > > > > > > It would be hard to determine the N above since the amount of > > > coding > > > > / > > > > > > > testing varies greatly across JIRAs. > > > > > > > > > > > > > > > > > > > I agree with Ismaël that there is an issue here. We currently > have > > > 969 > > > > > open > > > > > > JIRAs, 427 of them are unassigned and the remaining 542 are > > assigned > > > to > > > > > 87 > > > > > > people. The average of 6 issues per assignee is not that high. I > > > think > > > > > the > > > > > > problem is some of us (mainly component leads, including myself) > > have > > > > too > > > > > > many issues assigned. Top 5 of them have 218 issues assigned to > > > them. > > > > I > > > > > > believe these issues are automatically assigned for triage > > purposes. > > > We > > > > > > probably do not need to codify an exact set of rules,, we could > ask > > > > > > component leads regularly triage their components, including > > > > unassigning > > > > > > issues. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 16, 2017 at 3:20 PM, Ismaël Mejía < > ieme...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > Thanks Ahmet for bringing this subject. > > > > > > > > > > > > > > > > +1 to close the stale PRs automatically after a fixed time of > > > > > > inactivity. > > > > > > > > 90 > > > > > > > > days is ok, but maybe a shorter period is better. If we > > consider > > > > that > > > > > > > being > > > > > > > > stale is just not having any activity i.e., the author of the > > PR > > > > does > > > > > > not > > > > > > > > answer > > > > > > > > any message. The author can buy extra time just by adding a > > > message > > > > > to > > > > > > > say, > > > > > > > > 'wait I am still working on this', and win a complete period > of > > > > time, > > > > > > so > > > > > > > > the > > > > > > > > longer the staleness period is the longer it can eventually > be > > > > > > extended. > > > > > > > > > > > > > > > > I agree with Thomas the JIRAs should still stay open but > should > > > > > become > > > > > > > > unassigned because the issue won't be yet fixed but we want > to > > > > > > encourage > > > > > > > > people > > > > > > > > to work on it. > > > > > > > > > > > > > > > > Other additional subject that makes sense to discuss here is > if > > > we > > > > > need > > > > > > > > policies > > > > > > > > to avoid 'stale' JIRAs (JIRAs that have been taken but that > > don't > > > > > have > > > > > > > > progress)?, for example: > > > > > > > > > > > > > > > > - Prevent contributors/committers from taking more than 'n' > > JIRAs > > > > at > > > > > > the > > > > > > > > same > > > > > > > > time (we should define this n considering the period of > > > > staleness, > > > > > > > maybe > > > > > > > > 10?). > > > > > > > > > > > > > > > > - Automatically free 'stale' JIRAs after a fixed time period > > with > > > > no > > > > > > > > active work > > > > > > > > > > > > > > > > Remember the objective is to encourage more people to > > contribute > > > > but > > > > > > > people > > > > > > > > won't be encouraged to contribute on subjects that other > people > > > > have > > > > > > > > taken, this > > > > > > > > is a well known anti-pattern in volunteer communities, see > > > > > > > > http://communitymgt.wikia.com/wiki/Cookie_Licking > > > > > > > > > > > > > > > > On Wed, Aug 16, 2017 at 10:38 PM, Thomas Groh > > > > > <tg...@google.com.invalid > > > > > > > > > > > > > > > wrote: > > > > > > > > > JIRAs should only be closed if the issue that they track is > > no > > > > > longer > > > > > > > > > relevant (either via being fixed or being determined to not > > be > > > a > > > > > > > > problem). > > > > > > > > > If a JIRA isn't being meaningfully worked on, it should be > > > > > unassigned > > > > > > > (in > > > > > > > > > all cases, not just if there's an associated pull request > > that > > > > has > > > > > > not > > > > > > > > been > > > > > > > > > worked on). > > > > > > > > > > > > > > > > > > +1 on closing PRs with no action from the original author > > after > > > > > some > > > > > > > > > reasonable time frame (90 days is certainly reasonable; 30 > > > might > > > > be > > > > > > too > > > > > > > > > short) if the author has not responded to actionable > > feedback. > > > > > > > > > > > > > > > > > > On Wed, Aug 16, 2017 at 12:07 PM, Sourabh Bajaj < > > > > > > > > > sourabhba...@google.com.invalid> wrote: > > > > > > > > > > > > > > > > > >> Some projects I have seen close stale PRs after 30 days, > > > saying > > > > > > > "Closing > > > > > > > > >> due to lack of activity, please feel free to re-open". > > > > > > > > >> > > > > > > > > >> On Wed, Aug 16, 2017 at 12:05 PM Ahmet Altay > > > > > > <al...@google.com.invalid > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > >> > Sounds like we have consensus. Since this is a new > > policy, I > > > > > would > > > > > > > > >> suggest > > > > > > > > >> > picking the most flexible option for now (90 days) and > we > > > can > > > > > > > tighten > > > > > > > > it > > > > > > > > >> in > > > > > > > > >> > the future. To answer Kenn's question, I do not know, > how > > > > other > > > > > > > > projects > > > > > > > > >> > handle this. I did a basic search but could not find a > > good > > > > > > answer. > > > > > > > > >> > > > > > > > > > >> > What mechanism can we use to close PRs, assuming that > > author > > > > > will > > > > > > be > > > > > > > > out > > > > > > > > >> of > > > > > > > > >> > communication. We can push a commit with a "This closes > > #xyz > > > > > #abc" > > > > > > > > >> message. > > > > > > > > >> > Is there another way to do this? > > > > > > > > >> > > > > > > > > > >> > Ahmet > > > > > > > > >> > > > > > > > > > >> > On Wed, Aug 16, 2017 at 4:32 AM, Aviem Zur < > > > > aviem...@gmail.com> > > > > > > > > wrote: > > > > > > > > >> > > > > > > > > > >> > > Makes sense to close after a long time of inactivity > and > > > no > > > > > > > > response, > > > > > > > > >> and > > > > > > > > >> > > as Kenn mentioned they can always re-open. > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Aug 16, 2017 at 12:20 AM Jean-Baptiste Onofré > < > > > > > > > > j...@nanthrax.net > > > > > > > > >> > > > > > > > > > >> > > wrote: > > > > > > > > >> > > > > > > > > > > >> > > > If we consider the author, it makes sense. > > > > > > > > >> > > > > > > > > > > > >> > > > Regards > > > > > > > > >> > > > JB > > > > > > > > >> > > > > > > > > > > > >> > > > On Aug 15, 2017, 01:29, at 01:29, Ted Yu < > > > > > yuzhih...@gmail.com > > > > > > > > > > > > > > > >> wrote: > > > > > > > > >> > > > >The proposal makes sense. > > > > > > > > >> > > > > > > > > > > > > >> > > > >If the author of PR doesn't respond for 90 days, > the > > PR > > > > is > > > > > > > likely > > > > > > > > >> out > > > > > > > > >> > > > >of > > > > > > > > >> > > > >sync with current repo. > > > > > > > > >> > > > > > > > > > > > > >> > > > >Cheers > > > > > > > > >> > > > > > > > > > > > > >> > > > >On Mon, Aug 14, 2017 at 5:27 PM, Ahmet Altay > > > > > > > > >> <al...@google.com.invalid > > > > > > > > >> > > > > > > > > > > >> > > > >wrote: > > > > > > > > >> > > > > > > > > > > > > >> > > > >> Hi all, > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> Do we have an existing policy for handling stale > > PRs? > > > > If > > > > > > not > > > > > > > > could > > > > > > > > >> > we > > > > > > > > >> > > > >come > > > > > > > > >> > > > >> up with one. We are getting close to 100 open > PRs. > > > Some > > > > > of > > > > > > > the > > > > > > > > >> open > > > > > > > > >> > > > >PRs > > > > > > > > >> > > > >> have not been touched for a while, and if we > > exclude > > > > the > > > > > > > pings > > > > > > > > the > > > > > > > > >> > > > >number > > > > > > > > >> > > > >> will be higher. > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> For example, we could close PRs that have not > been > > > > > updated > > > > > > by > > > > > > > > the > > > > > > > > >> > > > >original > > > > > > > > >> > > > >> author for 90 days even after multiple attempts > to > > > > reach > > > > > > them > > > > > > > > >> (e.g. > > > > > > > > >> > > > >[1], > > > > > > > > >> > > > >> [2] are such PRs.) > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> What do you think? > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> Thank you, > > > > > > > > >> > > > >> Ahmet > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> [1] https://github.com/apache/beam/pull/1464 > > > > > > > > >> > > > >> [2] https://github.com/apache/beam/pull/2949 > > > > > > > > >> > > > >> > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
