> On Apr 11, 2018, at 10:37 AM, Mojca Miklavec <mo...@macports.org> wrote: > > On 11 April 2018 at 16:18, Joshua Root wrote: >> >> Certainly let's encourage contributors who have something to submit to >> use PRs. But I don't know that simply moving existing tickets over to >> PRs without the involvement of the original contributor will be useful. > > In any case I don't think that just transfering the commit without: > - making sure that lint passes > - making sure that livecheck passes and reports no newer version > - making sure that the port builds on at least one OS version and that > it at least runs > makes much sense. It doesn't have to be the original author who does that. > >> Most of the open submission tickets have problems that need to be >> addressed before they are committed. > > In many cases there was just lack of feedback from committers, even if > some issues were addressed. > >> And yes, if a submission has been reviewed and changes have been >> requested, and the contributor has not responded after a reasonable >> amount of time, and nobody else has volunteered to fix it, the ticket >> can be closed. > > We could move them to something like "changesneeded" (not sure where > exactly; they could get a special status, even if closed, but it > should be easy enough to find them should anyone have motivation to > fix the remaining issues). Just because none of us took the time to > review the changes for long enough that all dependency and the > software itself became completely outdated in the meantime, doesn't > mean that we should make the submissions non-discoverable and give the > signal to users that first of all we don't care for 5 years, and when > we start caring, we boldly close all the tickets. > > Very often I see tickets getting status "upstream", "infoneeded" etc. > which basically means that developers would ignore such tickets until > something happens. Or perhaps "helpneeded" which means that they are > genuinely interested in fixing the issue, but have no resources to fix > it. We need something similar.
At the moment, only 18 of 403 open submission tickets are less than 12 months old. A further 23 are between 12 months and 2 years old. In the past, I have browsed non-current submission tickets looking for any that I can handle (eg bibclen). However, most of the open submission tickets I’ve looked at, I’m unable to help with. Usually they involve a technology or build system that I don’t know (Rust, Java, etc). Other tickets are stuck for various reasons such as an inexplicable build failure, etc. IOW, there is very little low-hanging fruit among the 400 open tickets. Mass converting to pull requests is likely to just clog the PR queue with, essentially, dead submissions. Perhaps it is rude, but I think we should auto-close submission (and request) tickets that haven’t had any activity for a period (say 4-6 months, maybe less). The close message should encourage the submitter to try reopen, if they wish, thus resetting the clock. Perhaps there should be an automatic warning after a shorter period of inactivity that the next step will be to auto-close. How many submitters would actually wait for any length of time? If you need or want a piece of sotware enough to create a submission ticket, why would you wait passively for months or years? If a ticket isn’t acted on in, at most, a few months the submitter must have found another way to scratch their itch. Or the itch wasn’t serious. IMHO, YMMV, … Craig
