Mailspring Community Transition

Information
#1

Happy 2021!

As some of you may have noticed, Mailspring development was largely stalled during 2020 (and no surprise, given what that year was!) There was a bit of concern about Mailspring being abandoned, but thankfully, rumors of the project’s death were greatly exaggerated.

Statement from Ben Gotow

Hey folks! Hope everyone had a safe and happy new year — I appreciate the thoughts and discussion here, and I’m excited to announce some big changes coming to Mailspring as we look into 2021!

Since I originally launched the project (by adopting and partially re-writing Nylas Mail) in 2016, the Mailspring community has grown by leaps and bounds. More than 250,000 people have tried Mailspring across Mac, Windows and Linux, we’ve added tons of features, translated the UI into 13 languages, and addressed and closed more than a 1,000 GitHub issues.

2020 was a super challenging year in a lot of ways, and development fell off and eventually stopped for the last half of the year. In 2021, I’m determined to return the project to a regular release cadence with bug fixes and new feature development, to elevate contributors who can help maintain it, and reduce our “bus factor”.

To that effect, I’m excited to announce that I’ve brought on @CodeMouse92 as a volunteer community manager! He brings expertise in organizing online communities and will be a huge help tagging, triaging and taming GitHub issues. He will likely be restructuring our issue submission templates, process, and labels, etc. in the coming months. He’s also a skilled developer and Linux user, and I’m super excited to have his help fixing bugs and more rapidly addressing problems on the Linux platform.

To better facilitate contribution, we’re replacing the Mailspring community Slack with a discussion board (coming in the next day or two) that will be home to themes, plugins and conversations about issues and potential features. Our goal is to make it easier for developers and potential contributors to look at GitHub issues and find actionable ways to help by restricting issues to ready-for-development bugs, tasks and features, while giving questions, themes, etc. first-class categories of their own in a discussion forum.

We’ll also be assembling a new roadmap and collecting community feedback to identify what new features should take priority alongside bug fixes in 2021.

Finally, I will make it a priority to help folks submitting PRs with detailed feedback and code review (like @Phylu’s awesome new “colorized accounts” PR we’re about to merge! #2240). My goal is to share my knowledge about the codebase and enable as many people as possible to contribute in a significant capacity.

Thanks again - I appreciate the community support and I’m excited to see where the project goes in 2021!

-@bengotow

Meet Discourse!

We’ve spun up this gorgeous Discourse instance to house all future Mailspring conversations. Bug reports, feature suggestions, and development conversations will take place here from now on. We encourage you to join in — you can sign up using your GitHub — and participate in the conversation.

Please make sure you read the Code of Conduct to ensure this space remains friendly and productive for everyone. This Code of Conduct will also be deployed on our repository.

If you want to help us work on Mailspring, you’re welcome to post over in the appropriate subcategory of #development.

What About GitHub?

GitHub will continue to be the home to our development work. Code is still contributed through Pull Requests. Issues will contain tasks the developers have decided should be worked on in the near future.

As of 12 January 2021, we’ll no longer accept bug reports and feature requests on GitHub. Only contributors should create tasks there; all others will be closed. Please use Discourse for all future issues.

Issues Migration

Over the next couple of months, we’ll be migrating open issues from GitHub to here on Discourse. Here’s how that process works:

  1. All prior open issues are marked as Audit, meaning they’re under consideration for migration.
  2. The following issues will be marked as Stale and closed + locked.
    • Any bug report or feature request with no activity since 2018.
    • Any issue relating to the Mailspring service from before 2021.
  3. Some issues will be pruned:
    • Duplicate issues.
    • Some features.
    • Most “add support for X environment” requests. (We’ll take note regardless.)
  4. The rest of the issues will be marked as Migrated and closed + locked:
    • Bug reports will be migrated to topics in #bugs, with link(s) to the original issue(s).
    • Feature requests will be migrated to topics in #features, with link(s) to the original issue(s).
  5. Once we decide to take on an issue, one of two things will happen:
    • One of the original GitHub Issues will be reopened.
    • A new GitHub Issue better summarizing the issue will be created.

Through all of this, please know that we do care about the Mailspring users! There’s a lot that goes into fixing bugs and implementing features. Please read About the Bug Reports category and About the Feature Suggestions category to learn more.

Why Bother?

An uncontrolled pile of issues creates a negative feedback loop. Too many open issues discourages the developers from working on the code — it feels insurmountable — and scares away new contributors. Lack of maintenance work means bugs continue to pile up. Although some may be duplicates, wishlist-type suggestions, and otherwise invalid issues, no one is brave enough to dig through the slush pile.

Discourse allows us to establish a perimeter around GitHub, so the coding tooling remains a psychologically safe and welcoming place for developers to work on Mailspring. Remember, this project is largely maintained by volunteers working on their own time! No one wants to dig through a stressfully large issue list after work.

Can I Help?

YES! There are three ways you can help us.

Help Transition Issues

Any open issue on the Mailspring GitHub marked with audit needs to be audited and transferred. Whether it’s your own issue, one you care about, or just one that looks interesting, you are encouraged to create a Discourse topic about it in the appropriate category. Then, just comment on the task that you have done so, and we’ll come around and close it as migrated.

Don’t worry if the issue is something we’d prefer to mark as duplicate or stale. We can handle that later.

Help Build the Community

Help us get the word out about the new Discourse, and of course, just start posting! Let’s get conversations going.

  1. We’d like developers of Mailspring Plugins and Themes to post their work here on Discourse, in the #plugins and #themes tags respectively, and to share their knowledge in #development:plugins-dev and #development:themes-dev.
  2. We want anyone interesting in helping fix bugs or add features to start chatting in #development.
  3. We really want users and fans of Mailspring to help answer questions and share their knowledge in #help. Tutorials encouraged!
  4. We’d like anyone interested in adding localizations to get the conversation going in #development:localization.

Questions? Comments?

Just reply to this thread if you have any questions or comments, and we’d be happy to answer.

6 Likes
Mails persist in the trash after emptying the trash or the junk
#2
#3
#4

I am trying to create a new bug report in Discourse, but it fails with “Sorry, new users can only put 2 links in a post.” even though my post doesn’t contain any links. Any advice?

#5

That is odd!

I’ve cleared you as a normal user, @0xdec, so you should be able to post it now. If not, PM me.

1 Like
#6

@CodeMouse92 could you explain why discourse is better than GitHub discussion + proper labelling for GitHub issues (label every new issue triage, anyone who wants to fix something filters those out)?

To me, it just adds a barrier for bug reports, people already have a GitHub account (and discourse can be very annoying with the emails it sends out) and now people who do use GitHub also no longer get all notifications grouped together there.

Issues piling up in discourse doesn’t really seem better than them piling up in GitHub, it just moves them out of view.

#7

I understand your perspective, but in practice, it actually is working better for us, and the community as a whole.

A few (but not all) of the advantages thus far:

  • Help/Q&A and Issues are on the same platform; we can move them as necessary, instead of duplicating as before. (We were able to phase out Zendesk, which wasn’t serving us well.)
  • Having distinct category views for bugs, sync issues, service issues, and feature requests helps keep things organized better than labels did.
  • Duplicates can actually be moved, rather than just linked.
  • Voting system is more consistent in behavior than reactions, and merging duplicates will also merge the votes.
  • Better moderation tools. (We really needed them.)
  • GitHub Issues is freed up exclusively for active developer tasks, containing technically vetted and confirmed diagnostic notes. User-reported issues usually contain a lot of discussion and “me too” type posts, which make it easier for relevant notes to get buried.
  • Search features are more robust, and discoverability is improved.
  • GitHub notifications are no longer getting clogged up for the primary developer, who literally could no longer make use of GitHub notifications at all for the second half of 2020 largely because of that. This led to PRs going untended. (Activity on Discourse does not all automatically generate notifications for him, or anyone else on the project; instead, we can monitor and subscribe to things as needed.)
  • Discourse newsletter feature summarizes new activity, making it more digestible.
  • Discourse provides a full community environment, which had been requested.

Above all: the UI workflow on Discourse is encouraging a default user behavior of discovery and discussion, versus the default user behavior of “just create a new issue and leave it” that we had on GitHub. Duplicates are actually being created less often.

As to your own concerns…

To me, it just adds a barrier for bug reports, people already have a GitHub account

Discourse uses the GitHub SSO, so the barrier is minimal. I understand it’s slightly inconvenient one time for a few seconds for any given user, but it’s better than the prior system overwhelming the developers every single day.

discourse can be very annoying with the emails it sends out

You can disable any or all of those in settings.

… people who do use GitHub also no longer get all notifications grouped together there.

Again, the primary developer was getting too many notifications there, rendering GitHub largely useless to him. We didn’t have much community engagement there anyway; most people just complained that their particular desired features hadn’t been implemented yet. Since moving, we’ve had a lot more community engagement.

Reminder: You can use email or live notifications on the topics or categories you choose here on Discourse if you want to know what’s going on. I know it’s slightly more inconvenient for the casual user, but the first priority has to be for it to be usable for the main developers.

Issues piling up in discourse doesn’t really seem better than them piling up in GitHub, it just moves them out of view.

In fact, it’s made them more visible. Between categories, search features, and voting, we lose track of issues much less easily here than on GitHub with labels.

3 Likes