Package repository maintenance

[Arcanemagus]

I've been thinking about a few of these things on and off and figured it was time to write them down somewhere and get some feedback. What do people think about requiring the following for new repos and working on implementing them for current ones?

• Basic CI tests:

  Even if this just tests that the package installed correctly and activates this will be better than we currently have for a lot of the packages.

• Enable Greenkeeper for all repositories:

  This will automatically watch the packages for dependency updates and submit PR's when they are necessary.

• Specs for options:

  Of the few packages that have specs currently I don't think any test that the options work properly

• Enable protected branches

• Enable required CI tests

• .gitignore, .npmignore and the like for repositories

• .editorconfig and .gitattributes:

  Should we force EOL to be LF on all repos, or just leave it on auto? Either way something should be put in place to clean this up.

[steelbrain]

Here's my 👍 on all of them

I would very much recommend we use LF in all repos for consistency

[SpainTrain]

Some ideas regarding documentation:

• Standard set of badges
• Consistent contribution guidelines (I've seen these in all the repos, dunno if they are consistent/updated) and possibly CoC
• Maybe overkill, but would be nice if config options for the linter were in the README (see below)

[AsaAyers]

What's the purpose of config options in the readme when Atom has a settings page for manipulating those options?

[SpainTrain]

for folks who prefer to just edit their config.cson

[steelbrain]

I am personally 👎 on the idea of adding configs to README

[SpainTrain]

It also let's you see how configurable a linter is before installing it. Useful if you need a particular feature or are comparing two alternatives.

[SpainTrain]

I am personally 👎 on the idea of adding configs to README

any particular reason?

[steelbrain]

@SpainTrain Because then we have redundancy, we have to add title and description in two places in package, and there's a possibility of getting out of sync

[AsaAyers]

Same here. There's no reason to document what you can and can't do when we provide have a UI that provides built in validation.

I don't see anything wrong with maybe listing what can be configured, but it definitely shouldn't be documented to the point where you know the exact keys and schema to go poke at the config file manually. That's just asking for trouble.

[SpainTrain]

This is all being automated (I thought), so it won't be out of sync.

Hmm. In the menu bar there is an option to "Open Your Config" and atom documents its config schema in its docs (https://atom.io/docs/v1.3.0/using-atom-basic-customization#configuring-with-cson). Direct manipulation of the config file sure seems like a first-class supported feature in atom and documenting config options for packages seems in line with that support.

While I agree folks should be dissuaded from hacking their config directly, I am very skeptical that providing convenient documentation is going to drive anyone's behavior one way or the other.

While I do think documenting the config is the least compelling suggestion in this thread, I don't think it is completely asinine or out of left field. Certainly not a "need to have".

[Arcanemagus]

Parsing out the readme to find where the config is documented, making sure it matches the current code, and not screwing up any extra wording in the readme is not a task I would want to take on, you are welcome to it though if you feel like that is something that users would want. 😉

Documentation like what you linked I think is left over from before Atom had a settings menu for those options, and they have been maintaining it since it was already in there. In my opinion If a user wants to manually edit their config they should already know enough not to screw it up, and if they don't know that they shouldn't be touching it in the first place.

That does bring up another thing: Better documentation of the settings in the app. Or at the very least a review of them since some settings really deserve better descriptions.

[SpainTrain]

I'd never suggest any tasks I wouldn't plan to implement myself 😉 and have done something similar in the past. Agree it's low value vs. work, though.

Also agree that it would be higher value to ensure quality of the descriptions that are presented in the UI. Perhaps there's some way to implement a lint/stylecheck? Error if the description is not present, warn if it's extremely short?

[Arcanemagus]

Looks like activationHooks might be reliable again in v1.4.0 since atom/atom#9527 landed, if that turns out to be true making all of the linters only activate when a file of their language is first opened will be a huge boon to startup times.