5 ms·

I'd love to know the background of how something this comprehensive is created and maintained. Was this the work of one person? A team? Was it created in one g

I'd love to know the background of how something this comprehensive is created and maintained. Was this the work of one person? A team? Was it created in one go or did it start small and evolve? Very impressive!

alexeldeib 4y ago
Probably helps that the first suggestion is to PR the README :) More seriously, I agree. Reading this doc, the values, etc, make me want to work for this company I’d never heard of before.
dblock 4y ago
(I was CTO of Artsy then.) tl;dr The README became possible because Artsy is open-source by default, and someone just decided one day to create a repo and some content, and didn't need permission to do so. It's also the repo that most new hires read before they even apply to the job, and they don't need permission to make changes either. GitHub workflow is how everything gets done. More practically, check out https://github.com/artsy/meta/pull/1 https://github.com/artsy/meta/pull/1, which is one of the repos that merged into the handbook via https://github.com/artsy/README/pull/1 https://github.com/artsy/README/pull/1. Also note that Artsy was founded in 2010. This handbook in its current iteration is 7-8 years in, but its content goes back to ~2011 in some kind of evolution. You'll want to check out https://artsy.github.io/blog/archives/ https://artsy.github.io/blog/archives/ as well.
- stakhanov 4y ago
  Does one of these documents (or any other source, not necessarily from Artsy) explain this concept of "open-source by default" and permissionlessness in and of itself? I know the book "Turn the Ship Around" which talks of the difference between a culture of asking permission versus announcing intentions etc. Is it sort of like that?
  - orta 4y ago
    I was working at Artsy while the OP was CTO (:wave:) and tried to help out a bunch on fostering a good attitude towards OSS - there's quite a few notes in both artsy/README and the blog - (the making of artsy/README) https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/ https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/ - (OSSing our apps) https://artsy.github.io/blog/2019/04/29/how-did-artsy-become-oss-by-default/ https://artsy.github.io/blog/2019/04/29/how-did-artsy-become... - (OPs writeup on the philosophy) https://code.dblock.org/2015/02/09/becoming-open-source-by-default.html https://code.dblock.org/2015/02/09/becoming-open-source-by-d... - (the RFC process) https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/ https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/
  - dblock 4y ago
    Thanks orta for the links! On not having to ask permission. We failed early. Had a wonderful demo day. Tons of sign ups. It started getting a bit long. Someone decided to shorten each session (max 2 minutes) and choose which ones were worth demoing. So you basically asked for permission to demo. Sign ups stopped. Nobody wanted to demo anymore. Demo day died and took a year to restart properly. In general, establish “how”. Everything is in writing and GitHub workflow. When someone says “can I?” the answer is “why are you asking and haven’t done it (submit PR) yet”? This moves permission to a public discussion. Think in terms of must have, should have, nice to have, not allow/disallow. Managers already have the power to veto, so they don’t need to approve, allow or disallow. Managers need to say that to everyone all the time - “you have an idea, why haven’t you done it yet?”. Everyone needs to do things very visibly and over communicate to enable gentle redirects and avoiding getting to veto. Losing control is hard. Communications team wanted to review and control the engineering blog. I said hard no multiple times with every new comms leader. Asked them to comment on PRs. Don’t fix problems that don’t exist. If someone wants a knob that looks like permission, ask them what problem they are trying to solve.
    - deleted 4y ago
      [deleted]
    - kepler4243 4y ago

alexeldeib 4y ago

Probably helps that the first suggestion is to PR the README :) More seriously, I agree. Reading this doc, the values, etc, make me want to work for this company I’d never heard of before.

dblock 4y ago

(I was CTO of Artsy then.) tl;dr The README became possible because Artsy is open-source by default, and someone just decided one day to create a repo and some content, and didn't need permission to do so. It's also the repo that most new hires read before they even apply to the job, and they don't need permission to make changes either. GitHub workflow is how everything gets done. More practically, check out https://github.com/artsy/meta/pull/1 https://github.com/artsy/meta/pull/1, which is one of the repos that merged into the handbook via https://github.com/artsy/README/pull/1 https://github.com/artsy/README/pull/1. Also note that Artsy was founded in 2010. This handbook in its current iteration is 7-8 years in, but its content goes back to ~2011 in some kind of evolution. You'll want to check out https://artsy.github.io/blog/archives/ https://artsy.github.io/blog/archives/ as well.

stakhanov 4y ago
Does one of these documents (or any other source, not necessarily from Artsy) explain this concept of "open-source by default" and permissionlessness in and of itself? I know the book "Turn the Ship Around" which talks of the difference between a culture of asking permission versus announcing intentions etc. Is it sort of like that?
- orta 4y ago
  I was working at Artsy while the OP was CTO (:wave:) and tried to help out a bunch on fostering a good attitude towards OSS - there's quite a few notes in both artsy/README and the blog - (the making of artsy/README) https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/ https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/ - (OSSing our apps) https://artsy.github.io/blog/2019/04/29/how-did-artsy-become-oss-by-default/ https://artsy.github.io/blog/2019/04/29/how-did-artsy-become... - (OPs writeup on the philosophy) https://code.dblock.org/2015/02/09/becoming-open-source-by-default.html https://code.dblock.org/2015/02/09/becoming-open-source-by-d... - (the RFC process) https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/ https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/
- dblock 4y ago
  Thanks orta for the links! On not having to ask permission. We failed early. Had a wonderful demo day. Tons of sign ups. It started getting a bit long. Someone decided to shorten each session (max 2 minutes) and choose which ones were worth demoing. So you basically asked for permission to demo. Sign ups stopped. Nobody wanted to demo anymore. Demo day died and took a year to restart properly. In general, establish “how”. Everything is in writing and GitHub workflow. When someone says “can I?” the answer is “why are you asking and haven’t done it (submit PR) yet”? This moves permission to a public discussion. Think in terms of must have, should have, nice to have, not allow/disallow. Managers already have the power to veto, so they don’t need to approve, allow or disallow. Managers need to say that to everyone all the time - “you have an idea, why haven’t you done it yet?”. Everyone needs to do things very visibly and over communicate to enable gentle redirects and avoiding getting to veto. Losing control is hard. Communications team wanted to review and control the engineering blog. I said hard no multiple times with every new comms leader. Asked them to comment on PRs. Don’t fix problems that don’t exist. If someone wants a knob that looks like permission, ask them what problem they are trying to solve.
  - deleted 4y ago
    [deleted]
  - kepler4243 4y ago