Prepare for the Sunset of Atom

[confused-Techie]

While I am admittedly new to this fork of Atom it seems to have the most traction out of other forks. And while unfortunate the ReadMe doesn't differ from the main project I had a hard time understanding how set up this project is. Mainly if this project has the ability to host community plugins?

Because if not I would be happy to assist in getting that setup with code or with server resources to throw at it.

Really it may be time for laying out a roadmap of how to fully continue Atom with the main project disappearing.
If there are any resources to learn where this project stands in comparison we could hopefully begin with some beginner friendly issues to get it going.

So basically how can the community help, let us know.

[shellscape]

Yeah I stumbled across this org/repo via issues in the upstream and I'm pretty confused about what's going on here. 353 commits ahead of upstream, but the tags don't match between this fork and upstream, and none of the supporting documentation has been updated here. Lots of scoped commits that don't match any scopes I'm familiar with from conventional commit, lots of merge commits in master (squashing is your friend, folks!) Doesn't look like contribs here are following the guides in CONTRIBUTING.md either, which is fine, but the meta should be cleaned up to reflect the current state of things.

I'm an original beta-1 Atom user and would love to contribute to a community project, but as this is, it's a bit of a mess.

[AlexWayfer]

lots of merge commits in master (squashing is your friend, folks!)

Not for team work in my experience, but I'd not argue.

[aminya]

The scope of this fork was to provide IDE experience, which doesn't include updating the Atom-related documentation. But since then the scope has become broader, so now we will update the docs.

Lots of scoped commits that don't match any scopes I'm familiar with from conventional commit, lots of merge commits in master (squashing is your friend, folks!)

That's how we prefer to merge the commits. We deliberately do not squash the commits as it preserves the original logic and history behind the changes and also the contributors of each individual change. It also allows testing features against individual incremental changes. The source of a bug or breakage can be easily found by checking out each commit. This is not possible after a big squashed commit that could break many features and pull requests. See this for the background.

Doesn't look like contribs here are following the guides in CONTRIBUTING.md either, which is fine, but the meta should be cleaned up to reflect the current state of things.

Yes, they should be updated to match our guidelines. The documentation, like contributing.md is what the upstream tried to follow and not exactly what we wanted. We use commitlint for the commit messages in all the other packages.

[ElectronicsArchiver]

And while unfortunate the ReadMe doesn't differ from the main project

#380