New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process draft #1315

Merged
merged 5 commits into from Feb 22, 2018

Conversation

Projects
None yet
4 participants
@smashwilson
Member

smashwilson commented Feb 21, 2018

This is an effort to document the way that we collaborate on the design and development of this package. It's based on an in-person meeting between @kuychaco and I where we attempted to formalize the way we work, and make some implicit conventions and practices that we use explicit. I've made a pass over our notes and done some wordsmithing; @kuychaco, please let me know if anything I've written here differs from your understanding of what we said 馃槈

While a lot of this is what we're already doing, some of it is aspirational. Process is always hard to judge before it's put into practice, so we'll refine this as we go.

@simurai, one of the big things that we wanted to accomplish with this was including your input even though our timezones overlap so little. Let us know if you think we've mentioned you where you'd feel most useful, and if there's anywhere else you'd like to be involved that we haven't said 馃槃

Rendered

@smashwilson smashwilson requested review from simurai and kuychaco Feb 21, 2018

@smashwilson smashwilson added this to In Progress 馃捇 in Short-Term Roadmap Feb 21, 2018

@simurai

"click merge whenever you're ready". 馃槃

:sparkles: _Fabulously_ :sparkles:
This is an attempt to make explicit the way that the core team plans, designs, and works day to day on the GitHub package. Our goal is to reduce ambiguity and uncertainty and improve communication, while avoiding artificial confinement and ceremony for ceremony's sake.

This comment has been minimized.

@simurai

simurai Feb 21, 2018

Member

Since this document will be public, is there a risk that the community feels like they have to follow these guides. In the first sentence it says the core team, but that could be easily missed.

On the other hand, might be not bad when people start to write rfcs's before making PRs?

This comment has been minimized.

@smashwilson

smashwilson Feb 21, 2018

Member

Ah, good question. We've talked about writing a separate document for external contributors ("how to get your pull request merged") but we've punted on it for the time being. I think we'd want to involve @lee-dohm in crafting that one, as well, and maybe adopt it beyond this package if the outcome is positive.

On the other hand, might be not bad when people start to write rfcs's before making PRs?

I'd actually love to see this, especially for people tackling "big" changes, but I also don't want to mandate it for everything. Maybe modifications of existing design can be done first as a PR against an existing RFC? (That's not how "real RFCs" work, but we have commit history here...)

Long story short: that merits its own guide, content to be determined. Maybe we could research how projects like Kubernetes or Rust do this?

##### Process
1. Propose these changes first in a conversation in Slack, a stand-up, or another synchronous channel. The decisions to be made here are:
* Does this change make sense to people other than me?

This comment has been minimized.

@Arcanemagus

Arcanemagus Feb 21, 2018

Add at least one (the correct amount is two) space(s) here (and in the other similar level bullet points) in order for them to be properly indented when rendered.

This comment has been minimized.

@smashwilson

smashwilson Feb 22, 2018

Member

馃憤 Got it, thanks. I've also added a "rendered" link to the PR description too.

When you merge a fix for a bug, cherry-pick the merge commit onto to the most recent release branch, then run `apm publish patch` and update `package.json` on the most recent beta release branch on the `atom/atom` repository. This will ensure bug fixes are delivered to users on Atom's stable channel as part of the next release.
When you merge a fix for a **security problem**, a **data loss bug**, or fix a **crash** or a **lock-up** that affect a large portion of the user population, run `apm publish patch` and update `package.json` on the most recent beta _and_ stable release branches on the `atom/atom` repository. Consider advocating for a hotfix release of Atom to deliver these fixes to the user population as soon as possible.

This comment has been minimized.

@Arcanemagus

Arcanemagus Feb 21, 2018

Should this be hotfixed to the branch of the currently released minor version on Atom stable? As written this could involve an update of several minor versions of github to the stable branch for a "hotfix".

This comment has been minimized.

@smashwilson

smashwilson Feb 22, 2018

Member

Ah, good catch. I think I confused myself quite a bit when I was transferring this from our notes 馃槃

Also: this is kind of cumbersome. I actually advocated for us not to do this way back when we were getting started because it adds a lot of complexity and ceremony. If we end up having to do this more than once or twice I'll likely get us a script we can use to make sure the fixes go to the right branches and such. 馃

smashwilson added some commits Feb 22, 2018

@kuychaco

Looks great! Thanks for word-smithing!

@smashwilson smashwilson merged commit 45f9350 into master Feb 22, 2018

3 checks passed

ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

Short-Term Roadmap automation moved this from In Progress 馃捇 to Complete 鉁 Feb 22, 2018

@smashwilson smashwilson deleted the process branch Feb 22, 2018

@smashwilson smashwilson removed this from Complete 鉁 in Short-Term Roadmap Apr 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment