Make ckib16 a contributor

[JoshCheek]

Purpose

This issue is written to @ckib16, so from this point forward, I'm going to talk directly to him you. I'm making this issue so I can have a place that explains why I'm doing this that isn't dropped in the middle of one of the other issues.

How to close this issue

Read through this issue, and if we're on the same page, you can close it. Closing it will illustrate that you do have contributor access (b/c otherwise you can't close the issue) and implies that you've read the issue and understand / are on board with the things I say here.

The need

To work on #110, you'll need contributor access (unless I want to micromanage everything you do, which I don't). You may additionally need it for #111 because it may require editing the readme (eg you might wind up moving info between the two, you'll probably need to update links, at the very least).

Vetting

Looks like you've sent me 2 PRs, (#112, JoshCheek/atom-seeing-is-believing#26), for documentation changes, one I merged. This establishes a 3 month history of interest in SiB.

This tweet implies that your interest stems from a similar ideology about learning and discovering for oneself based on effective feedback systems.

You've offered to work on two issues (#110, #111) that don't require us to have similar programming opinions. This implies a positive motivation, and nicely sidesteps the separate set of issues we might have if you wanted to work on the code.

Your github history has projects going back close to 4 years, so I can assume a general familiarity with the tools.

Scope

So, I thought about it a bit and decided that you seem thoughtful and I can probably trust you to take an appropriate amount of care if I give you contributor access.

• You genearally have permission to edit / open / close issues as you see fit (if you think of it like a garden, watering, pruning, rearranging). If you're less than 70% confident regarding something you're about to do, then you can ask, otherwise just do whatever you're thinking. It's easy enough to undo (posts can be edited, issues can be reopened, so there's no danger if you act based on an opinion that I disagree with) This should be sufficient to complete Move some issues to wiki #110 I was about to say that "edit as you see fit" isn't congruent with the additional constraints I list in that issue. But I don't need to say that because granting contributor access means trusting that what you see fit aligns with those constraints, or alternatively, that you'll be thoughtful enough to find an appropriate solution if it differs.
• You have permission to edit the wiki and the readme as you see fit. This should be sufficient to complete Better home page for the wiki #111 Going forward, you're welcome to edit as appropriate. If it's a significant change, then you may wish to open an issue to solicit feedback. I'll leave that up to your discretion.
• You can push changes to the readme directly to master. The readme is part of the wiki integration, keep the goals in mind, and use your discretion to decide whether the changes you make merit a conversation to consider them. If they don't, then you don't need to make an issue or PR for it, you can push it to master directly. For example, Updated readme with exact time of video mention #112 you can make changes like that on master and push them without seeking my blessing. Do note that there is some risk with this privilege: if you're careless you may commit files or changes you didn't mean to. We can of course always fix it, but I'd much prefer you be thoughtful about it so I don't have to inspect everything you do (note that I will definitely see everything you do, as I won't be able to push until I merge your changes locally and I read the commits to stay up to date). I don't know what your dev habits are, but here's an easy set of heuristics that should suffice: never force push (if the histories differ, figure out why) always do git status before and after adding a file, always do git diff filename before adding a file, this way you don't accidentally commit changes and files that you didn't mean to (this is what enables my cavalier development style, I can be as haphazard as is useful because I know that I'll catch the dumb stuff when I stage the changes). You're probably comfortable with git, but if you get in a difficult situation, let me know and I'll look at it with you.
• Don't push code changes. So the above authority to push to master is not for the code. If it's in spec, lib, features, bin, then use a PR.

Welcome

Figured I should close this with something positive, so welcome ^_^ Contributions are appreciated but not expected, don't let it be a burden.

[ckib16]

Thanks Josh - great set of expectations laid out above.

Yup - I am fully on board with your intent. I have zero intention of pushing any code whatsoever. I wish I understood the workings of SiB to contribute code, but honestly, at this point I don't.

I'll just be re-organizing the wiki and documentation. No hurt feelings at all if you don't like my changes.

[ckib16]

Just posting for future reference:

Here are two write-ups on the only other technique I know of for allowing edits to wikis. I have never used it, seemed more complex than I ever needed/wanted because it involves syncing repos etc. But just so you have the info:

1. Enabling pull requests on GitHub wikis
2. How To Use GitHub Wikis For Collaborative Documentation