Yarn's day-to-day maintenance

[arcanis]

Now that Yarn literally supports half the Javascript ecosystem I think we should figure out a way to make it more likely that we receive day-to-day contributions to Yarn. By day-to-day I mean things like:

• Tagging/closing issues
• Reviewing/merging pull requests
• Improving our documentation

The typical contributors we have fix the problems they have then disappear. While it's nice to have a constant flow of contribution, it's also slightly overwhelming for me, and we probably would all benefit from a more uniform responsibility.

• Should we start publishing on Yarn's front page the companies that employ our core contributors (if both of them wish to)? This would give them an extra incentive to allow their developers to spend time helping Yarn. We could revisit the companies on the front page every six months or so.

• The yarnpkg teams are a bit opaque imo - there's a lot of people inside the org that I never saw contribute, and I'd prefer to give visibility to our active contributors (as a kind of reward).

  • Maybe we should remove the per-company teams (especially if we advertise such companies on the front page), and remove everyone who isn't in the @yarnpkg/core team from the organization.

  • Instead, maybe we should have a @yarnpkg/contributors team where would be automatically added anyone with a merged PR. That's something that Gatsby does and it feels nice to have a friendly message inviting us to a "private" group after our first contribution gets merged.

    • People in this team would have review permissions and tag permissions.
    • They would still be subject to the CoC, of course.
    • We could post the changelog in this group after each release to keep people engaged.
    • Maybe @KyleAMathews or @DSchau could share some of their experience on this?

• We should probably try to have some core contributors on Windows. We periodically try to support people on it (and our testsuites runs on Windows as well), but having someone taking responsibility to approve Windows PR would be awesome.

• Most of the issues we have (and a good chunk of the PRs, unfortunately) are too old to be acted upon - in most cases they've already been fixed, or were wontfix, ... basically hard to do anything about. We made a huge work at the time of the 1.0 release to review them all, but I'm not all that certain it had a lot of impact compared to the time investment (plus a lot of them were left open waiting for more details that never came).

  • Should we have a bot to close stale issues?

Do you have other ideas?

[DSchau]

@arcanis thanks for mentioning us--let me fill in a few details as to how we do things and happy to help with whatever, too!

Also @jlengstorf was instrumental in getting some of this set up, so his insight would be valuable here too!

maybe we should have a @yarnpkg/contributors team where would be automatically added anyone with a merged PR

As you noted--this is what we do. I think it's huge in gaining a sense of community and growing involvement in that community. We go a step farther and invite to a swag store (with a coupon code) on the first PR merged--which is pretty slick!

When you establish this community, you also then have a great avenue to share relevant information, news, changelogs, etc. We post a weekly Gatsby Gazette to this group, which is effectively a newsletter with the latest Gatsby news, features, etc.

Note: need to be a Gatsby Maintainer to view the link--but I know @arcanis is 🙌

We could post the changelog in this group after each release to keep people engaged

Not sure how regular your release cadence is--but this could get a bit noisy. We publish daily, so our "weekly wrap up" seems to work pretty well, but it is a bit more of a manual process, e.g. hand-picking the valuable features, changelogs, etc.

We should probably try to have some core contributors on Windows. We periodically try to support people on it (and our testsuites runs on Windows as well), but having someone taking responsibility to approve Windows PR would be awesome

We also struggle with this. Our Windows tests run in Appveyor and Azure Pipelines (as yours do?)--neither of which really report back timely feedback. It is nice to have the sanity check, but it's hard to ensure we get this 100% right. If there are other alternatives here--we'd love to check them out!

Should we have a bot to close stale issues?

As you may know--this is what we do and we've seen our issues go down quite a bit. We haven't as of yet applied this bot or similar functionality for PRs, but it's something we've certainly considered. If it helps, here is our process/flow:

• Issues older than 20 days, get a label stale? (if the label "not stale" is not present)
  • The bot posts a comment, e.g. "This issue hasn't had a reply in quite some time. If we don't hear back soon, we'll be closing out this issue!"
  • If anyone comments, the issue falls out, and we revisit it 20 days later (if applicable)
  • If the label "not stale" is applied, the logic short circuits and we won't revisit
• If after 30 days, 0 replies, and the label "stale?" we close the issue out.

This has worked fairly well for us. We use Peril, and our configuration is here. We'd love to mess around with Github actions or something, but haven't as of yet been able to access/experiment with any of that stuff!

Hopefully this is helpful! Please feel free to reach out if we can help with anything else!

[jlengstorf]

I don't have anything to add beyond what @DSchau said, but I'm happy to answer questions or help out if I can! 💜

[torifat]

I used to triage issue every now and then. The main problem for me was the amount of issues I got assigned with. It was overwhelming. Happy to lend a hand again.

[Daniel15]

Our Windows tests run in Appveyor and Azure Pipelines (as yours do?)

@DSchau I was going to try to move the whole Yarn build across to Azure Pipelines (currently only the end-to-end tests run on Azure Pipelines) but never had the time to work on it. Our release process actually has a lot of complexity because we build most artifacts (tarball, Debian package, RPM package) on CircleCI, and the Windows installer on AppVeyor. Consequently, the release scripts need to handle only publishing the new version once both the CircleCI and the AppVeyor builds complete successfully. Occasionally we have a case where the CircleCI build of a tag works but the AppVeyor build fails, so we end up with a half-released version. Moving everything onto one build system would simplify it a lot.

Should we have a bot to close stale issues?

I'd love us to lock old closed issues too. A non-trivial amount of email in my inbox consists of people replying to issues that were closed a while ago, posting about something that looks similar but is actually a different issue.

[arcanis]

@DSchau @jlengstorf thanks for your input! I hope we can learn from that 😃

I'd love us to lock old closed issues too.

I'd be ok with that - I definitely noticed the same. The one concern I'd have is the initial email spam we'll trigger when we close the 1600+ issues currently in the repository. Any idea how to avoid that?

[KyleAMathews]

Email filters 😅

…

On Fri, Mar 15, 2019, 10:19 PM Maël Nison ***@***.***> wrote: @DSchau <https://github.com/DSchau> @jlengstorf <https://github.com/jlengstorf> thanks for your input! I hope we can learn from that 😃 I'd love us to lock old closed issues too. I'd be ok with that - I definitely noticed the same. The one concern I'd have is the initial email spam we'll trigger when we close the 1600+ issues currently in the repository. Any idea how to avoid that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7110 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEVh6YZ9udsvuh-otEHUCvCT3BRehzMks5vW4_ggaJpZM4bz5t0> .

[DSchau]

@arcanis @KyleAMathews yeah - filters are probably the best approach, honestly.

@arcanis one thing you could do is give a little lead time, e.g. create the maintainers group and then post an update where you can give some recommendations like e-mail filters or something else.

Honestly - I don't even use e-mail any more for this stuff. One thing I've really liked is we have a #github channel in Discord where all PRs, issues, etc. flow through.

also heh 👋 on the ping--replied back 😄

[arcanis]

My main concern actually was from our users PoW :D Assuming an average of ~2 participants per conversation, that's still a bunch of people who will suddenly receive notifications on old topics! Oh well, I guess they won't mind if it only happens once 😅

[DSchau]

@arcanis it's sort of unavoidable 😅 Best you can do is warn or make people aware!

[jlengstorf]

@arcanis we throttled our bot to avoid a deluge. You could do something like limit the bot to 5–10 issues a day — this will take a while to work through 1600+ issues, but it spreads out the messages.

(Though you could also make the argument that getting 1 or 2 emails a day from GitHub vs. 100 all at once might be more annoying, but... 🤷‍♂️)

[rally25rs]

We also have PRs dating back to 2017 that we should probably clean up.

For me, It's a lot easier to support issues (make comments, tag things, reproduce problems) than to review PRs. The biggest catch with PRs is "would the yarn team really want this?" It makes it hard to accept a PR when you aren't sure if the feature or change being requested is something that should be a part of yarn. (that and I do PR reviews at work all day and it gets daunting to do at home too 😢 )

---

On closing old issues; I hate when repos do that (npm does it too IIRC) but I totally understand that it's a bit unavoidable. If it hasn't been working in that much time, it's unlikely it ever really will... But to me it always feels very dismissive "well i didn't bother reading your issue for a couple weeks so too bad"

Maybe in the close message we word it in a way that encourages the issue opened to contribute to the solution. Something like "We are closing this issue due to it's age. If this issue is still affecting you, please help to resolve it by ..." and including a link to some kind of "how to contribute" page.

---

[jlengstorf]

On closing old issues; I hate when repos do that (npm does it too IIRC) but I totally understand that it's a bit unavoidable.

@rally25rs we don't like closing without a course of action, either, so our bot does two things:

1. Posts a 10-day warning (example) with instructions for preventing the issue from closing
2. Close the issue with a message noting that it's automated, so mistakes can happen, and providing next steps if a valid issue was closed in error (example)

Adding a link to how to contribute is a great idea! We have one of those (gatsby.dev/contribute) but haven't linked it from the bot messages.

[olingern]

I was just looking over some of the recent issues myself. I think a bot could help a lot. vscode has a lot of issue churn, and their vscodebot does seem to help with that. I think a lot of Yarn's issues get triaged, but ( sometimes ) the issue opener never provides more info. There are probably a lot of duplicates floating around the repo.

vscode's bot has a few neat features that help them tackle these sort of repo chores:

• auto closes after a period of no activity with the label needs more info
• Auto closes questions meant for StackOverflow and locks conversations to collaborators.
• Duplicate search

It would be nice for a bot to have a feature to autoclose incomplete issues after a certain period of time. For example, these recently opened issues: #7288, #7287, #7286 are all incomplete.

---

Also, I think it could be helpful to have more labels so that contributors who have experience in certain parts of the codebase can quickly filter issues they'd like to pickup, i.e. builld, resolutions, workspaces, etc.

[mollyIV]

Hello 👋

Just wanted to share the few things that help us working on fastlane project on the daily basis. We basically leverage the power of a bot, labels, issue triage and GitHub templates.

Bot

The bot is doing the following (among the other things):

• adding warning message to opened issues when there is no activity for more than a month: issue
• closing an opened issue when there is no activity after the week since warning message was added: issue
• locking closed issues older than 2 months: locked issue;
• adding needs attention label to opened pull requests older than 2 weeks;

To get more details, you can find a source code of the bot here.

GitHub templates

To simplify an issue creation process, fastlane uses categorized (bug, feature, ...) GitHub templates:

• 🐛 Bug Report
• 🚀 Feature Request
• ❓ Support Question
• 😱 Regression
• Don’t see your issue here? Open a regular issue.

Summary

I believe using a bot in yarn repository could be a great help. Seeing almost 2k opened issues seem to be overwhelming, especially for a new contributors.

Looking for an issue to help with is quite difficult - there are many cases when a fix is done, but the issue is still opened.

GitHub Templates could simplify and speed up getting a context of the issue and it could allow to avoid a description like:

Do you want to request a feature or report a bug?

Feel free to ask questions about our workflow, will be happy to help 🙂:bow:

[arcanis]

Thanks for your input! I've started to automate a bit more the Berry repository (where most of the v2 work happens), we already have some issue templates, and I think by the release we'll have the auto-close bot.

The main question I need to solve is where to host it - I'd prefer to avoid relying on too many external services (we already have Github Actions, Netlify, Azure). I think Azure now supports cron jobs, so it might be a good option!

As for this repository, I might leave it as it is to avoid sending thousands of emails 🤔

[Daniel15]

@arcanis I could always host it on my server if you'd like. Some of the release infra (eg. signing the Windows package, building the Debian repo, archiving the "nightlyt" builds) runs there. I've been meaning to see which parts can move to something like Github Actions, although the signing is likely something we'd keep off third party servers.

[jcrben]

I'd love us to lock old closed issues too.

Please do not lock issues. Often someone can point to asimilar newer issue which will help someone, and searching thru old issues is a very common way for me to debug (similar to searching stackoverflow) or understand background design decisions. Plus I believe they still do get tracked by search engines.

I realize that locking issues is a trend, but it's a very user-hostile one. Not clear what the upside is either - if you want a bot task to removes maintainers as watchers when it is closed, I'd be fine with that.