welcome.md page

[rueckstiess]

@kangas, @imlucas how's this?

[rueckstiess]

Comments from the review on Reviewable.io

---

^{docs/welcome.md, line 64 [r1] (raw file):}
these 3 links need to be fixed. for now, we can link to the files in mongodb-js.github.io (this repo). Eventually, they should link to the empty template repo (for khaos).

---

[imlucas]

Comments from the review on Reviewable.io

---

^{docs/README.md, line 6 [r1] (raw file):}
Looking at other patterns, this (./docs/README.md) should be merged into ./README.md

---

^{docs/welcome.md, line 1 [r1] (raw file):}
Move this to ./CONTRIBUTING.md

---

^{docs/welcome.md, line 11 [r1] (raw file):}
This isn't quite right and is the most long running and painful problem in the community... See the ubuntu.sh example.

Want to just have this be the once place all other repos can link back to so we can all stop writing this same description over and over again :) (See long rant in this node-forward discussion )

---

^{docs/welcome.md, line 31 [r1] (raw file):}
Let's just farm this out to GitHub's knowledge base: https://help.github.com/articles/set-up-git/#setting-up-git

2. Setup Git

---

^{docs/welcome.md, line 34 [r1] (raw file):}
We'll need to make another gitter room anybody can join because of some weird semantics (already have to be a member of the mongodb-js org to get to https://gitter.im/mongodb-js :()

---

^{docs/welcome.md, line 45 [r1] (raw file):}
Hmm. Perhaps we should think about this a bit more. Seeing it written up, I can only imagine how confusing this would be for new contributors... If all apps will end up in the mongodb or 10gen org, mongodb-js is just micro-modules and we only need to mention that.

---

^{docs/welcome.md, line 49 [r1] (raw file):}
Could we explore what kind of notification options review tools like reviewable offer? It's up to you to make a code review happen would cause me to respond as a contributor like "pfft I'm never doing code reviews then, brah.".

Curious to hear your thoughts on this. Perhaps there is something we could do with all repos having at least two maintainers (also relates to who makes sure the build stays green, responds to issues etc). Let's circle back to this though after letting it bake for a while though.

---

^{docs/welcome.md, line 64 [r1] (raw file):}
Can we just remove this for now and replace with @todo's? Still under active discussion #8 (diff)

---

^{docs/welcome.md, line 67 [r1] (raw file):}
This isn't quite right... @see https://github.com/10gen/mongoscope/blob/dev/docs/dev.md#sublime-text

Also think the complexity of explaining this/cognitive burden for new contributors is just too high not to automate it all.

---

[rueckstiess]

Comments from the review on Reviewable.io

---

^{docs/README.md, line 6 [r1] (raw file):}
ok

---

^{docs/welcome.md, line 1 [r1] (raw file):}
ok

---

^{docs/welcome.md, line 11 [r1] (raw file):}
Ok what is the right way to install? I hope it's not

"pipe this random script from the internet to your bash as root"

:)

---

^{docs/welcome.md, line 31 [r1] (raw file):}
ok

---

^{docs/welcome.md, line 34 [r1] (raw file):}
speechless...

---

^{docs/welcome.md, line 45 [r1] (raw file):}
But even for micro-modules (at what point does it become macro?), personally I'd prefer to have a master and dev branch. I just wanted to allow "master-only" for folks who really just want to put a single function in mongodb-js and be done with it. Allowing both is fine I think.

What part do you find confusing? the nvie writeup? Or the text here?

---

^{docs/welcome.md, line 49 [r1] (raw file):}
Would be nice if reviewable solves this somehow.

I mostly wanted to make clear that we put the changes directly in a feature branch on the repo (as discussed this morning), as opposed to a fork.

How about I'll phrase the code review sentence like:

If you want a code review, ask on gitter ...

---

^{docs/welcome.md, line 64 [r1] (raw file):}
ok, will remove these links for now.

---

^{docs/welcome.md, line 67 [r1] (raw file):}
I picked a few from your list but not everything is required. I don't write coffeescript for example or intent to look at binary hex. Can't force all this stuff on everyone.

automating is fine, but knowledgable people might just want to add manually. once we have automation for this we can add a sentence like

quick and easy way to get all these plugins is: mj init --sublime

---

[imlucas]

Comments from the review on Reviewable.io

---

^{docs/welcome.md, line 45 [r1] (raw file):}
Confusing in terms of being a new contributor. But I think github might solve this on their end: if you're using nvie's flow, you have develop as your default branch so all new PR's default to going to that branch. Same goes if you have master as the default branch and using a different model than nvie's.

Like style, perhaps we can leave this to repo owners and just say you need a ./CONTRIBUTING.md file in your root (our templates will take care of this for new stuff) that says here's the branching model we use etc.

Asides

• significance of calling it CONTRIBUTORS.md to GitHub
• why you need a CONTRIBUTORS.md

---

^{docs/welcome.md, line 49 [r1] (raw file):}
Yep all sounds good. Just connecting the dots from standup (on kernel team, getting your code reviewed is your responsibility) with other questions that have come up around maintainers (weird admin only GH settings woes, Issue Watch responsibilities, etc).

---

^{docs/welcome.md, line 67 [r1] (raw file):}
Good points. Just one logic change then:

If you use Sublime Text as your editor, you may find these plugins from [Sublime Package Control](https://packagecontrol.io/installation) useful:

---

^{README.md, line 3 [r2] (raw file):}
Ah. Much better! Thanks!

---

[imlucas]

Comments from the review on Reviewable.io

Reviewed files:

• CONTRIBUTING.md @ r3
• docs/README.md @ r2
• docs/welcome.md @ r2
• README.md @ r2

---

[imlucas]

Comments from the review on Reviewable.io

Reviewed files:

• README.md @ r4

---