Potential Roadmap Atom Community Release

[kaosine]

For anybody reading this wanting to help out but unsure where to look, here's all the major repos undergoing change:

• Atom Core

• Atom Frontend/Docs This is my personal repo for working on the website for this. Docs need refactoring and to get rid of custom tags while I work on the getting the front working. I should have things setup and easy to understand

• Atom Backend/API @confused-Techie 's repo, if you have any question for now ask him. More explanation below

Major Development Items (all these are in some form of progress as of right now but all could use some help here and there)

1. CI Working Again
2. The current one semiworks, but this is one major sticking point as of right now. (this point will have to be updated as I get more current info).
3. We are currently using a older windows image in azure that is getting ready to be discontinued and just generally building the things needed for the pipelines
4. Continue upgrading Electron
   1. We're up to V12 right now thanks to a PR by Mauricio, but we're still behind farther than we should be
   2. Realistically we should probably stay at least 1-2 versions with in the current release in the future once we have steady dev flow going
5. API backup
   1. This involves backing up the atom.io database and a few other components @confused-Techie
   2. This is how the Windows and Mac apps auto-update and there should be some way to possibly integrate this within linux as a option?
   3. This is also vital to some workflows like getting the auth token for github with viewing the packages, updating and modifying entries on there.
   4. Switch to apm-papm(this can be found under the repos under the organization here for atom-community) @aminya
6. Website and documentation
   1. This involves bringing the documentation and the site back online
   2. The site needs to be a good landing point outside of the github for all the resources we have.
   3. The documentation needs to be refactored and finished (these have been pulled from the old flightmanual repo)
   4. Update branding - knowing how Microsoft is about branding with projects it's taken over and either sunsetted or used the name for their own projects, we've decided it's best we rebrand and tentatively the name is going to be Pulsar from discussions we've had in the discord(see #polls channel for more on this)

I'm currently working on this last part with the website and documentation in my personal ac-website repo with hopes to push it up soon. If anyone wants to help with fixing the current documentation to allow for it to function properly and not throw errors in compilation you're more than welcome to pop over and take a look. I'm more concerned with trying to fix the layout and add more content to the front pages right now.

Not to mention this is a preliminary roadmap to be possibly converted to the projects layout. Any updates and clarifications would be helpful so I can tag who is working on what and add as necessary. These updates will likely push us to a potential 2.x release once we have the api, core, and everything else in a proper working function. Especially thanks to Mauricio's updates bringing us to electron 12 and fixing a bunch of other things once his changes are filed in. If I tag the wrong person let me know, but I'm tentatively tagging those I know who are working on specific things for the current endgoals we have at this point.

[kaosine]

Also not sure what the potential deadlines we want to set for ourselves as well. I know we have until the end of the year at the bare maximum to make sure all the API's and CI point to our new places. But It might be helpful to set something for maybe the end of July to get a dev version out at the very least?

[confused-Techie]

My goal is to have everything for the API (except Github Auth dependent features) working by the end of this month. But as soon as we decide on a rebrand we can begin looking at the Auth setup for Github

[meadowsys]

peek if I may add, I may attempt to rewrite some native addons to use napi and do some monorepo-ing?

[kaosine]

I'm going to have to ask you to clarify parts of this to be honest. The mono-repoing especially because I'm not entirely sure how to word this part and I don't want it to turn out weird.

[meadowsys]

its just taking all the language-* packages and adding them into the main repository

[confused-Techie]

For anybody reading this wanting to help out but unsure where to look, here's all the major repos undergoing change:

• Atom Core
• Atom Frontend/Docs
• Atom Backend/API

[Digitalone1]

I suggest other two possible points.

1. Changing the name of the project since I read somewhere, not remember where, that atom is a mark registered and Microsoft has its rights. If it's true, we have to look for another name.
2. Changing the licence to GPL? Why MIT? I don't like someone does like Microsoft that picks Code and then adds its own without sharing with the community.

[DeeDeeG]

I keep forgetting how permissive MIT is. Okay, so as long as we maintain the MIT notice to cover the parts where that still applies, moving to GPL for the overall project should be doable. GPL just puts the limit that redistributed code needs to have the source published somewhere. It's not against anything in the MIT license to go ahead and add that additional requirement. Can be discussed by the community what is preferred in regards to license.

[Digitalone1]

Not only that, the derivative work must be distributed under the same or equivalent license terms.

[aminya]

I don't like the idea of changing the license to GPL or evilization of other companies/organizations. The limitations of GPL do not allow us to freely use code from the outer world, and many companies might ignore Atom altogether. For example, an Intel library like MKL is not compatible with GPL, which means we cannot use that library for our native modules. Or, the companies that distribute proprietary packages like Tabnine will become incompatible.

[ThatXliner]

There's LGPL... but if I'm not mistaken, that kind of just applies to libraries.

Or, the companies that distribute proprietary packages like Tabnine will become incompatible.

What if we just make it so the editor itself will be open source, not necessarily the packages. I still would love to be able to freely edit the extensions instead of having to manually go to where the extensions are stored (e.g. VSCode)

[mauricioszabo]

I would prefer to leave the license as MIT. As much as I don't like some practices of some companies, I don't think re-licensing as GPL will be a step on the right direction or if will even help...

[kaosine]

Updated with the information from our renaming discussion in the discord in the #polls channel. Might be best to start over at 1.x but be clear of feature parity with Atom 1.6x. Just as a clear break from Atom and as a restart for us.

[ljsinclair]

I'm a tech writer and use Atom for writing, so would be happy to help with the documentation.

[icecream17]

I'm not opposed to chapters like in a book since many documentation structures are similar. (rust and python come to mind:)
https://python-chess.readthedocs.io/en/latest/
https://doc.rust-lang.org/book/

[kaosine]

Yeah the idea of a book structure honestly makes sense, since it'll probably make sense as a guide from start to finish of beginner friendly topics to the more advanced content. That's one thing I did like from the original atom documentation that's in there now that will need significant refactors and going off the outline I found in the original repo it's nowhere near done either. There's no telling how much work needs to be done to:

1. Complete it
2. Refactor for clarity
3. Get rid of extraneous stuff we probably don't need either in the "code" of the documentation or things that just are flat out not relevant.

Any help on those once I am able to start functioning again would be helpful, since writing documentation on my own isn't likely to come out exactly right even using tools like grammarly and the like to refine it(which I will be using externally and if I can figure it out I might fork out the documentation part and pull it in as a dependency for that folder(if I can figure out how to embed it in that way?). That way it can also be loaded into AC/Pulsar itself as needed. But most of that is way down the road. Just getting it functional looking and clear to anyone reading is the first goal first and foremost along with just completing as much of it as we can too.

[ljsinclair]

Okay, so what we're missing here is the answer to the first question I posed:

Who is the content for?

The answer helps determine the combination of:

• Delivery Mechanism -- the system the information is delivered (e.g., CMS, site builder, etc)
• Delivery structure -- the way the information is conveyed (e.g., tutorial/manual, knowledgebase/help, etc)

For example, Atom Editor has multiple audiences:

1. Those who want to use the editor as a tool (e.g., writers, tech writers, developers, engineers)
2. Those who want to develop additional functionality for the system (e.g., developers, engineers, architects etc)

Use as a tool

The people who want to use the system as a tool don't need a tutorial/manual. They need the basics to do their jobs, which includes:

• how to add git projects
• how to change theme/appearance
• how to add additional functionality with add-ons/plugins/packages, etc
• how to commit and push their content to the repository.

In this case, a knowledgebase/help system is more appropriate

Enhancements to the system

Those who want to add functionality to the system need to know:

• the underlying architecture, language, etc
• the package system/processes to add new functionality
• the process for working with the team to add enhancements, testing, PRs, etc
• API definitions, syntax, examples, etc

For this audience you can go with a "manual/tutorial" style help system and/or a knowledgebase.

[confused-Techie]

I really like how @ljsinclair has described the content, and think it would be really cool to really have two sections for the documentation. The way I see it, would be best shown as,
the user clicking onto the docs page nav, then being shown the two options

• Quick Start
• Documentation

This would naturally cause each group of documentation consumers to go the proper route, since end users, wanting to use it as a tool would click the 'Quick Start' and that can be tutorials, then those wanting to enhance the system would go towards the documentation.

This could be a simplistic way to create that divide in the docs a bit more naturally.

[ljsinclair]

Some additional comments

• Glossaries are your friend -- any term, standard, acronym, jargon goes into the glossary, ideally with a hyperlink to an overview page for further information
• FAQs are a subset of a glossary, but with questions and are equally useful BUT only when there are articles with direct answers to the questions -- don't create endless scroll articles and expect the user to work out what to do next.
• Content duplication is bad and causes all sorts of maintenance issues. Ideally the system will have the concept of the "include" file (this is Jekyll's term for it), but in short, it's reusable content.
• It's ok to start off with broad concepts, but break detail down into child articles.
• It's bad form in documentation and software development to create endless scroll files. If you don't write a programme in one huge file (prior to compiling and deployment) then it shouldn't happen in doco (I'm looking at you, VScode

[ghost]

If you don't change the link to Pulsar Edit, you'll see that AtomRebirth isn't being worked on.