Establish issue/pull-request triage or workflows

Is your feature request related to a problem? Please describe.

Our issue and pull request backlog are continuing to grow with many of them > 2-3 months old.

Given the changes to the codebase in the last few months, any stale PR need to be fully reworked and issues need to be re-examined.

Describe the solution you'd like
The VSCode team had similar problems keeping their issue and PRs clean (though at a much larger scale).

One of the mitigations applied was establishing a project triage policy.
In it they describe the timelines for issue and PR expiration as well as reasons for closure. By strictly adhering to the policy, the team managed to drive their outstanding issues and PR down considerably.

Describe alternatives you've considered
It seems no matter how many issues we close with "you should be asking for help on Discord" they just keep coming in, detracting from core isssues.

We could also just let pull requests languish in purgatory but all that does is scare off contributors and project managers that look at those stats to determine the health of the project.

How important is this feature to you?
Very much so!

I want to see this project earn widespread adoption and have spec'd it for use in production systems for next gen user experiences at my employer.

Additional context

Let's draw the line in the sand and just let go of the baggage we're lugging around.

If a policy is in place that says "you have 10 days to post a repro or the issue will be closed" then nobody should be surprised when the issue closes.

If a pull request needs rebasing/rework because progress has made it obsolete then the author should be given a timebox to complete the work or the opportunity to ask for more time. If either of those options are not exercised then it should closed, no fuss no muss.

There's got to be some Github bots or workflows out there somewhere to make this happen and enforce it.

I'll even volunteer for the first tour of duty.

@Rich-Harris, @pngwn, @mrkishi, @Conduitry, @tanhauhau what are your thoughts?

[tivac]

YES

[antony]

@dkondrad I agree with this. I think 10 days is a bit stringent, sometimes I just like to make people aware, but it can take a long time to find a way to make a repro, but some sort of time limit makes sense.

If we went bottom up on the issues list, I would say that a lot of them must be so stale now that they aren't even reproducible.

Oh - side-note, I too would be up for volunteering to at least close those issues I keep commenting on with a "come and chat to us" in discord and then begging the author to close. I doubt I'll have the bandwidth for much beyond that though.

[swyxio]

also, this project could use a regular maintainers meeting and/or people specifically tasked for docs/issue triage, non code work. gh now has special roles/permissions for this. would improve my confidence in both svelte and sapper to see this happen.

@antony,

Yeah, I just picked 10 days out of thin air. I work in industrial systems where it sometimes weeks to get to a root cause and my longest continuous investigation was 4 months!

Most bots I've looked at that are based on Probot have the ability for community members to ask for more time or up-vote issues and PRs.

I think the important aspect of the time limit is to cut down on the "drive-by" issues that come up as well as give the community a reasonable expectation. The VSCode document makes it very clear that they specify upper bounds and make no guarantees to how quickly they are going to get to the issue after it is has been triaged. They also deal with an exponential number of those one-off not-really-committed-to-helping-solve-the-problem type of reports. We'll just scale our expectations based on our particular volumes.

@sw-yx,

Yeah, I agree as well... maybe a restricted channel on Discord so that maintainers can have road-map and planning discussions. That way, we'd have automatic meeting minutes since Discord keeps logs for basically ever.

Yeah, so I'm not expecting a document as detailed and advanced as the one I linked to pop out of thin air, but I'd like to at least start collecting up some of the ground rules. Besides, the org is still missing a code of conduct (which this document would qualify).

To get the automation ball rolling, I'm going to setup a "bot arena" repo where we can test out some of the more popular bot apps. We'll invite Svelters interested to slam the repo with issues and pull requests to get a live demo of the available features. I'll post the the link once I have some of the bots installed and configured.

I'm also investigating using the Github API to siphon out our existing issues and clone them in the bot arena. I know they added the functionality to transfer issues between repos and I already found an example script to collect them using curl so I think its possible.

Made from progress with API data extaction and pull request patch extraction...

Here's the PRs that currently cannot be merged cleanly:
1863: Consume and generate sourcemaps | RedHatter
2684: add slots option to component constructor options object | creaven
2737: FIX #2446: apply bindings and event handlers in order | colincasey
2779: Resolve TODO in Actions tutorial | varholak-peter
2989: Support dimension bindings in cross-origin mode | mrkishi
3136: 3128: Test to show nested slots fails | cam-stitt
3308: ensures sequential lifecycle ending in afterUpdate | deviprsd
3349: on:* | matyunya
3419: Multiple classes with class:x,y,z={condition} | marceloadsj
3547: Factor out each-block code into helper functions | Swatinem
3587: Failing test for onError handler. | Crisfole
3725: wip: move a11y to its on file | tanhauhau
3766: Optimise parsed AST | tanhauhau
3822: Make $capture_state capture local state | rixo
3895: add scrollTop and scrollLeft bindings | Rich-Harris
3917: WIP: "interface" for exported properties | stalkerg
3928: <svelte:element> proposal implementation | erzr
4000: Fix #3125 | dasZGFz
4066: feat no invalidate reactive vars if dependencies are all static | tanhauhau
4073: WIP Allow custom elements to be rendered to light dom or shadow dom (open, closed) | fsodano

Here's a V2 PR that's been hanging around... what do we do with it?
3236: v2 Fix issue where class directives wouldn't work with spread props and class prop | umanghome

[benmccann]

For Chart.js we added a "stale" label. If we were waiting on the PR submitter for awhile we applied that tag. Then reviewers could easily filter those PRs out or skip over them. Triagers could ping those tickets every couple weeks to remind folks they needed some action. If there was no response after a couple pings then it'd be closed, which seemed gentler than closing relatively quickly. It took us awhile, but we eventually worked our PR queue down to single digits

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[benmccann]

We are aware of this and working on it. Mostly what we need is more help. We're hoping to be able to leverage donations we've gotten via OpenCollective for that purpose. That being said, we've also setup the stale bot as you can see 😄 We also just overhauled the issue templates. I think that writing some documentation about how we handle things and a contributor's guide to help on board people will also help. This is an area of work that will never be done, but is something we're constantly thinking about and continuously working on (despite the ever growing backlog). We're going to be trying different things here, so given the unclear end state I'm going to go ahead and close this to keep the issue tracker clean.