Growing the stylelint team

[jeddy3]

I think we should try to grow the stylelint team. Over the past two years, the number of stylelint users has grown significantly. The number of active stylelint team members has, however, remained pretty constant. Also, for most of the team, myself included, we don't have as much time as we used to to give to the project. There simply isn't enough time amongst us to review all the PRs and triage all the issues anymore.

I think growing the stylelint team would be healthy and would help the sustainability of the project.

There are a couple of contributors I can think of off-hand:

• @CAYdenberg has made a number of contributions over the past few months.
• @modosc has offered, and has started, to port some of the stylefmt fixes over as he has experience with the stylefmt code base.
• @gucong3000 has been active in both the stylelint and stylefmt.

@gucong3000 @CAYdenberg & @modosc Would becoming stylelint members be something you're interested in?

As team members:

1. You'll be able to help review pull requests, merge them and update the CHANGELOG.
2. You'll be able to help triage issues.
3. You'll be able to help put out releases.
4. You'll be able to help decide the direction that stylelint takes going forward (see: VISION.md).

(I'll try to knock-up, in the next couple of days, additions to the developer guide to formalise the first two of these. We have an informal approach to issues and PRs that isn't documented anywhere).

I'm sure there are a few more suitable people I've failed to mention. Shout out if anyone else is interested! Either because you wish to support a tool you use, or as an opportunity to get involved in a open source project. As we say in the developer guide:

If you like stylelint and open source software (since you're reading this, you almost certainly do), please consider taking some time to pitch in. Not only will you help stylelint thrive, you will also learn a thing or two — about CSS, PostCSS, Node, ES2015, unit testing, open source software, and more.

Also, are there any companies out there that use stylelint as an integral part of their tool chain and are able to spare some of their developers' time? If so, please let us know!

@stylelint/core What are your thoughts? Do you agree we need to grow the team? If so, got any ideas, other than asking the people listed above if they are interested, about how we could do this e.g. can our processes be improved somehow, can we lower the barrier to contributing, would a regular release cycle help etc?

[modosc]

i'd be happy to help

[hudochenkov]

I think growing the stylelint team would be healthy and would help the sustainability of the project.

It's a good idea! Candidates are also good.

I'm sure there are a few more suitable people I've failed to mention.

We could ask @Arcanemagus also. He's helping us with discussions on issues, and he's AtomLinter/linter-stylelint maintainer.

I'll try to knock-up, in the next couple of days, additions to the developer guide to formalise the first two of these. We have an informal approach to issues and PRs that isn't documented anywhere

When I started as a stylelint maintainer you gave me these instructions:

• Make *-empty-line-before keyword options consistent #1663 (comment)
• Rename "at-rules-without-declaration-blocks" to "blockless-at-rules" in max-nesting-depth #2275 (comment)

I guess they could be a good starting point for developers guide update.

Can our processes be improved somehow?

I think our processes are good. They are proven to keep sustainability and quality of stylelint, and its code base. The only thing we're missing is a time. But it's going to be better if we have a little more people on board. And I about to have more time to spend on stylelint development.

[Arcanemagus]

Thanks for the offer @hudochenkov, but I barely have time to try to keep up with all the repos in the AtomLinter org 😉. (Nevermind the fact that I know virtually nothing about CSS / PostCSS).

Feel free to tag me in issues or hit me up on Atom's Slack if there's something you would like input on from the perspective of an API consumer 😉.

[gucong3000]

stylelint is cool, I like it. I'd be happy to join.

[CAYdenberg]

I'd like to join as well, if the team agrees that all three of us are needed/wanted. No pressure either way 😃

My one question would be that if stylelint is growing to now 12(?) people with write access is there a need to discuss if specific people should be in charge of watching issues, providing code reviews etc..

[lvliang271486017]

i want you and i like to join in!

[jeddy3]

@CAYdenberg, @gucong3000 and @modosc Fantastic news that you're all interested!

@stylelint/core If there aren't any objections, and now that the pull requests and issue management guides are merged, I'm going to add them to the team.

(@Arcanemagus Totally understand. Thanks, as always, for your continued work on AtomLinter. Especially, the linter-stylelint package! :))

My one question would be that if stylelint is growing to now 12(?) people with write access is there a need to discuss if specific people should be in charge of watching issues, providing code reviews etc..

Good question. Only a handful of the existing 11 users are active, so there probably isn't enough scope, even with three new additions, to divide out the responsibilities. In the past, it's been informal where people have dipped into what they like and/or what they thought needed doing. We could continue like that for a while to see how things pan out and reassess it (once everyone has had time to settle in) if we think some formality would help. So, feel free to jump into the pull request list, issue backlog etc as you see fit for now :)

i want you and i like to join in!

@lvliang271486017 Thanks for offering to help out! There is a list of ways that you can help out and start contributing to the project. Good luck :)

[lvliang271486017]

@jeddy3 thanks

[hudochenkov]

No objections from me :)

There is one thing that we forget to add to docs/developer-guide/pull-requests.md. Never push to master. If you need to change something — create PR, even if it's a one letter change.

Also, I would like to ask new members, to have at least one older member approval on PRs at the beginning. To ensure new members are on track with our processes and vision.

[gucong3000]

Never push to master. If you need to change something — create PR.

We can disable this permission in here: https://github.com/stylelint/stylelint/settings/branches/master

[gucong3000]

Also, I would like to ask new members, to have at least one older member approval on PRs at the beginning. To ensure new members are on track with our processes and vision.

No problem for me, I'd love to.

[jeddy3]

There is one thing that we forget to add to docs/developer-guide/pull-requests.md. Never push to master. If you need to change something — create PR, even if it's a one letter change.

Sounds good. I'll expand out the Prerequisites section of the Developer Guide with this type of information. The pull request doc is specifically for reviewing them.

We can disable this permission in here:

Unfortunately, we can't disable it outright as we commit directly to master (via the website) when updating the CHANGELOG. I'm hesitant to change this process as it fixed issues we had with updating the CHANGELOG in the past.

[Arcanemagus]

@gucong3000 Note that those options you show only prevent force pushes, not regular commits, however the options you aren't showing (requiring CI checks) do prevent direct commits.

[ntwb]

No objections from me, everything above is awesome 💯

[jeddy3]

@CAYdenberg, @gucong3000 and @modosc I've sent you invitations to the stylelint organisation. Welcome onboard! :)

Please replace your local forks with a clone of this repo. This will make collaborating on (and rebasing) each other's PRs easier.

As I said above:

• You'll be able to help review pull requests, merge them and update the CHANGELOG.
• You'll be able to help triage issues.
• You'll be able to help put out releases.
• You'll be able to help decide the direction that stylelint takes going forward (see: VISION.md).

Please familiarise yourselves with the Developer Guide, as it'll help you with the above. In particular:

• The contributor guides i.e. working on rules.
• Core team guides i.e. issues, pull requests and releases.

Additionally, it's probably worth reading through the User guide too. In particular, how rules work together.

Don't hesitate to shout if you've any questions about, or have feedback on, these guides.

Feel free to jump into any of the issues or pull requests. Generally, we wait on external contributors to add the new rules and/or new options that they have proposed (so that they have the opportunity and time to get involved). But you can jump on them if it's something that you'll use yourself. More importantly, there are a few key areas that the stylelint team are trying to push forward:

• Making the linting engine more robust e.g. Fix isPathIgnored regression for .stylelintignore files #2833 and Update to postcss-selector-parser 3 #2757
• Growing the new autofix system and making it more robust e.g. Added non-file inputs support to autofix #2710, Add stylelint-disable commands support to autofix  #2643 and Add autofix to rules for parity with stylefmt #2829
• Addressing bugs e.g. bugs label
• Improving the performance of stylelint e.g. Fix require time performance #2454
• Shoring up our flow coverage (if anyone of you has experience with, or fancies learning, flow then please jump in!) e.g. Increase flow coverage lib/cli.js, lib/lintSource.js, and lib/needlessDisables.js #2823 and Increase flow coverage lib/createPlugin.js and lib/createStylelintResult.js #2714
• Empowering the ecosystem by improving our points of extensibility e.g. Add support for asynchronous processors #2502
• Improving our tests e.g. test label

Right, I think that's enough of an introduction to stylelint. Hopefully it has provided a good overview.

Feel free to use this thread for questions.

Welcome onboard again! :)

[hudochenkov]

Welcome, people! :)

[gucong3000]

@jeddy3 I didn't get an invitation.

[jeddy3]

@jeddy3 I didn't get an invitation.

Weird. Can you try again, please? I've updated the invite.

[m-allanson]

This all sounds great 👍 Welcome, everyone!

[gucong3000]

I still haven't received the invitation. Maybe the username is wrong, it should be gucong3000

[jeddy3]

I still haven't received the invitation. Maybe the username is wrong, it should be gucong3000

Strange. I've revoke the invitation and tried another from scratch. It's definitely the right username as your avatar is showing up :)

[ntwb]

The invitation should link to the GitHub Orginization rather than this repo I believe:

e.g: Something along the lines of: https://github.com/orgs/stylelint/invitation?via_email=1

[gucong3000]

@jeddy3 @ntwb All right now. Thank you.

[ntwb]

Congrats and welcome y'all :)

[CAYdenberg]

Thanks, everyone. Flow is a bit of a current interest of mine so I'll have a look at those two issues sometime soon.

[CAYdenberg]

So - I'd like to get some of the "stale" pull requests merged, especially those where I like what the author did but the tests are failing for whatever reason or there are issues that need to be addressed. Do we have a policy on just jumping in on other peoples PRs? I know other OS communities require you to branch from a branch and either submit a separate PR to master or a PR to the branch. What's good practice here?

[jeddy3]

So - I'd like to get some of the "stale" pull requests merged

That would be amazing!

Do we have a policy on just jumping in on other peoples PRs?

There's no offical policy (if only because we've been such a small team that nearly everything has, so far, been informal conventions). For other team member's PRs (that is branches off the main repo) we've generally added a comment to the PR saying you'll pick it up and then commit directly into that branch. For external contributors (working from a fork) it's a bit tricker and, I think, in the past we've just duped the work into a new PR.

Does this sound OK? More than happy to establish some other approach if you think it'll be benefical. I believe continuing to improve our processes will help keep the project sustainable.

[ntwb]

"For external contributors (working from a fork) it's a bit tricker and, I think, in the past we've just duped the work into a new PR."

Depending on the contributors pull request you may also be able to push directly to that PR

https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/

It's a pretty neat feature, my anecdotal analysis appears to be a 50% hit and miss, some contributors allow it, some do not.

"... we've generally added a comment to the PR saying you'll pick it up and then commit directly into that branch."

Per the above, I'd suggest adding a comment to any PR you're planning on picking up regardless.

I'm not sure there is a way to tell if you are able to push to a contributors pull request without actually trying it, so that's what I do, I'll try adding a commit to the checked out PR and follow that with a git push, if it doesn't succeed I'll just create a fresh branch locally and copy that checkout to the new branch and go from there.

[jeddy3]

Depending on the contributors pull request you may also be able to push directly to that PR

I didn't know about that. That's is neat!

[jeddy3]

I'm going to close this now as I think everyone is settled in.

This also seems like a good time to mention that stylelint just passed 1 million npm downloads a month. Congratulations everyone :) 🎉

[CAYdenberg]

Hey all, I've been a stranger lately as some contract work has come up, and also tightening my portfolio as I'm moving toward contracting fulltime sometime soon. Once I do leave my regular position I imagine my work level will ebb and flow somewhat.

[ntwb]

Thanks for the update @CAYdenberg, we've all been in that same position, and will again no doubt, good luck on the job front 👍