Yes I agree it should be on a case by case basis, no need for anything formal, it is just being a nice person and explaining to everyone why you are doing something.
- Bobby On Fri, Sep 15, 2017 at 4:19 AM Jungtaek Lim <kabh...@gmail.com> wrote: > 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) > > >>> > > >> > > > > >
