Thanks for all your voices. Regarding question, I'm not sure we can define the time and frequency for that. I don't mean to build a new item for bylaw. That actually depends on individual, and how much the issue is urgent. For example, we can't just wait author for inactive pull request addressing critical or even blocker issue, including 'effectively' blocker for release preparing phase.
Personally no updates (not code update but also no comment) in two months feels me as inactive and high chance to become stale. Someone may feel it too short, so maybe leaving comment before taking over and wait some more for others' feedback might be better. I feel similar for no code update but just reacting as leaving a comment more than three months. Three months are enough long to forget about their context of PR. Please keep in mind that above things assume that we are reviewing pull requests not too late. Inactivity due to late reviewing is out of topic. Similar consideration applies to JIRA issues which is in-progress but no patch is available. Thanks, Jungtaek Lim (HeartSaVIoR) 2017년 9월 15일 (금) 오전 1:40, Hugo Da Cruz Louro <hlo...@hortonworks.com>님이 작성: > Agree. Question is what is the reasonable time frame for a response, and > how many times one should reach out to a person asking for a response. > > > On Sep 14, 2017, at 8:43 AM, Stig Rohde Døssing <stigdoess...@gmail.com> > wrote: > > > > I agree, if the original author is not responding it seems totally fine > to > > me for someone else to finish up a PR. If the new PR is based on the > > previous effort, I think we should be careful to always preserve > authorship > > information. The easiest way is probably to keep the original commits. > > Ideally inactive PRs that we want to keep are rare enough that we can > live > > with keeping the original commits without making the commit log too > noisy. > > > > Amateur license parsing, so buyer beware: > > The way I understand "You represent that each of Your Contributions is > Your > > original creation" from the ICLA ( > https://www.apache.org/licenses/icla.pdf) > > is that it's probably not okay to take someone else's commits along with > > your own, squash them and submit the whole thing under your own name. > Point > > 7 mentions how to submit on behalf of others. > > > > The first comment here may also be relevant regarding license for an > > unmerged PR https://issues.apache.org/jira/browse/LEGAL-156 > > > > 2017-09-14 16:03 GMT+02:00 Bobby Evans <ev...@oath.com.invalid>: > > > >> I totally agree. If you have reached out to an author and there has > been > >> no response for either a bug fix or a feature that you want, then feel > free > >> to take it over. Just be polite about it and make sure it is clear to > >> everyone what you are doing. > >> > >> - > >> Bobby > >> > >> On Wed, Sep 13, 2017 at 11:19 PM Jungtaek Lim <kabh...@gmail.com> > wrote: > >> > >>> Hi devs, > >>> > >>> I have seen some old pull requests for bugfix and new feature going to > be > >>> stale. Some of us tried to ping to author several times but not respond > >> in > >>> some months. For new feature we may have to wait for authors, but for > >>> bugfix waiting authors means we are aware of the bug but we don't fix > the > >>> bug because of credit which doesn't make sense to me if we should wait > >> for > >>> months. > >>> > >>> So IMHO at least we may want to handle inactive bugfix pull requests > not > >>> too late, Maybe creating new PR addressing same thing without retaining > >>> commits, or taking over PR via retaining commits. If possible it may be > >>> ideal to take over inactive but valuable pull requests with retaining > >>> commits. > >>> > >>> What do you think about it? And does some of us know about any issues > >>> including license, authorship, or so if someone takes over inactive > pull > >>> request with retaining their credit (commits)? > >>> > >>> Thanks, > >>> Jungtaek Lim (HeartSaVioR) > >>> > >> > >
