What will we do with this repo?

[jasonkuhrt]

I would like to have a general consensus from our cloud software team about what we will use this repo for.

Who

I have chosen to limit the scope to the cloud software team because we are the smallest, least codified, most lean, and most dynamic (by number of discrete projects) software team at littleBits; we are the ideal trial group.

What

I propose that this repo be the place for us to openly discuss, codify, evolve, and reference our workflow.

1. "Openly" means that we share our thoughts in the public domain, welcoming external participation and also gladly influencing the external world.
2. "Discuss" means that we all share responsibility for workflow we choose and all final decisions are based on consensus.
3. "Codify" means that workflow choices manifest in written form. If its not written it does not count.
4. "Evolve" means that no workflow choice is final. We will always be open to discussing new ideas, revisiting old ones, and reevaluating our current workflow.
5. "Reference" means that this place will be how we will onboard new hires and contractors. We expect that by merely referencing this place people should be able to know what to expect and what the expectations are of them. Further, we think that be doing this "openly" others outside littleBits may come to reference this too; should they find it useful.

---

This is my goal with this repo. I agree with it. Check off your name once you do too, and/or discuss!

• @jasonkuhrt
• @stresslimit
• @sssyed

Once we have consensus, close this issue.

[geoflipman]

I think the parts about "openly sharing our thoughts in the public domain
with the external world" should be carefully considered.
It is not clear to me that we are now or will in the future be fully open,
so the leadership should be consulted.
Let's discuss this part first.

G

On Sun, Dec 14, 2014 at 10:31 PM, Jason Kuhrt notifications@github.com
wrote:

I would like to have a general consensus from our cloud software team
about what we will use this repo for.
Who

I have chosen to limit the scope to the cloud software team because we are
the smallest, least codified, most lean, and most dynamic (by number of
discrete projects) software team at littleBits; we are the ideal trial
group.
What

I propose that this repo be the place for us to openly discuss, codify,
evolve, and reference our workflow.

"Openly" means that we share our thoughts in the public domain,
welcoming external participation and also gladly influencing the external
world.
2.

"Discuss" means that we all share responsibility for workflow we
choose and all final decisions are based on consensus.
3.

"Codify" means that workflow choices manifest in written form. If its
not written it does not count.
4.

"Evolve" means that no workflow choice is final. We will always be
open to discussing new ideas, revisiting old ones, and reevaluating our
current workflow.
5.

"Reference" means that this place will be how we will onboard new
hires and contractors. We expect that by merely referencing this place
people should be able to know what to expect and what the expectations are
of them. Further, we think that be doing this "openly" others outside
littleBits may come to reference this too; should they find it useful.

---

This is my goal with this repo. I agree with it. Check off your name once
you do too, and/or discuss!

• @jasonkuhrt https://github.com/jasonkuhrt
• @stresslimit https://github.com/stresslimit
• @sssyed https://github.com/sssyed
• @alin-littlebits https://github.com/alin-littlebits

Once we have consensus, close this issue.

—
Reply to this email directly or view it on GitHub
#1.

Geof Lipman

director of engineering | littleBits http://littlebits.cc/

snap the internet to anything

[jasonkuhrt]

My proposal is to take the codified workflow as far as it can be made open. I'm interested in things like Github Flow which I think would be quite silly, even counter productive, to not be open about. I also am interested in focusing on the cloud team right now because of the aforementioned reasons. We can put to practice industry standard and open-source standard practices that work for our pod. This is a small scale of 2-4 people. I was hoping to avoid bureaucracy at such a scale.

[stresslimit]

@geof-littlebits chatted with Jason, we're talking about things that are completely not high-security, or even specific to our organization particularly; feel free to ignore :)

[jasonkuhrt]

@stresslimit You're the last remaining check. That makes you this issue's closer too.