Soft launching into the next 90 days

We soft launched with a 5-minute talk at Wicked Good Ember almost 10 days ago. Since then, we’ve been hard at work launching this blog, making our WordPress development work with Vagrant and making our API development work with Docker.

We’ve been paving the way to let people get started with documentation and refactoring, and sketching outlines for new features.

We’ve gained a number of new contributors eager to get started but often lacking the tools to do so.

Now it breaks my heart to say this, but Code Corps is not ready to be our go-to organizational tool just yet. It still can’t give the insight we need into prioritization or actionability for you to be productive. We still have to rely heavily on a mix of Slack, GitHub issues, and even this blog.

So how do we fix that? This post lays out our plan for the next 90 days or so. By the end of the summer, our goal is to have a fully functioning product that you couldn’t live without. And we hope to have a self-sustaining core team without having to rely on outside consulting to pay the bills.

If you want to jump to something particularly interesting to you, here’s an outline. These items are listed in priority order, though documentation and refactoring will be ongoing projects.

Document the API
Document the Ember app
Refactor API tests
Refactor Ember tests
Add deployment of feature branches
Add Stripe integration for crowdfunding platform
Redesign tasks
Add ability to assign tasks
Add GitHub repos to projects and posts
Add email onboarding for users
Add project goals to projects
Add project updates to projects
Add GitHub authentication
Connect GitHub repositories to projects

Document the API

For fairly obvious reasons, the API is one of the most important things we need to work on. The API is the first point of interaction for developers working on both the front-end and backend.


We’ve found that API Blueprint makes the most sense for writing documentation for our API. It’s human-readable and machine-readable. Later, this blueprint can be used to hook into our tests to verify the contract that the API sets for the API and its clients.

This GitHub issue outlines all the different endpoints we need to cover.

I had hoped to spike the first parts of the blueprint before publishing this post, but perhaps an adventurous person can spike this out this weekend. We ideally also need a sort of blueprint blueprint. If I’m adding a new endpoint or model, how should I approach the task of documenting it? We should document this in our guides so that a new developer knows what to do.

Document the Ember app

The Ember app also deserves documentation. This is more straightforward in that we should take services, components, models, etc and document them using YUIdoc.


I had also hoped to spike this out before this post was published, to provide an example. If someone would like to take this on, it would be extraordinarily helpful. We should also document how to write YUIdoc documentation in our guides so that a new developer knows how to document in the future.

Here’s the relevant GitHub issue for this.

Refactor API tests

Many of our API tests are kludgy and could use refactoring and simplification. This is an ongoing task without a hard deadline, so dive in where you please and take this on.

Refactor Ember tests

Our Ember tests could use some very specific refactoring. The biggest win and the lowest-hanging fruit is to rewrite our tests with page objects. The relevant GitHub issue outlines how to do this and what tests still need done.

Add deployment of feature branches

Right now reviewing other peoples’ pull requests happens to be a little tedious. Wouldn’t it be great if we could deploy our Ember app with a revision hash and view that revision on the same public server? This isn’t so hard, and we have a GitHub issue for that.

Deploying the API in a similar way is going to be a bit harder and requires more thought. If anyone wants to tackle that, head over to this GitHub issue.

Add Stripe integration for crowdfunding platform

Running Code Corps incurs a lot of little costs and a couple big ones. Things like servers and SaaS subscriptions start to add up.

More importantly, I think that most projects like Code Corps will always need a devoted full-time core team. No matter how many contributors we have, coordinating our efforts will always be a full-time job.

So far, Nikola and I have been managing this by consulting at Coderly in our full-time job and moonlighting with Code Corps on the side. Of course, this is not sustainable in the long-term.

And Code Corps is supposed to be a platform for other projects to do the same. Part of our experiment is not just to coordinate time and talent, but to help projects sustain their core teams with a reasonable amount of funding.


Part of our core functionality then includes a crowdfunding platform. And it makes sense to start on this now rather than later. A number of people have already asked how they can contribute money where they don’t have time. Every day that passes without a good answer to that question feels like a loss.

Of course, the risk is launching donations…and no one donates. Or we raise so little money that it looks embarrassing. We’re just going to have to suck it up and take those risks. We simply can’t delay learning.

There’s a GitHub issue that serves as a dumping ground of ideas right now. I’ve also been drafting a better outline of this feature, and will edit that issue when it’s finished. If you’re interested in helping to tackle this, join that issue and we’ll keep you posted.

Redesign tasks

At the outset of this post I said that Code Corps is not yet ready to be our organizational tool. Why?

It’s hard to know how to act on tasks. It’s hard to know who’s working on tasks. It’s hard to know where tasks currently stand. Is it ready for review? Ready to merge? Needs some more work?

We initially modeled our designs after GitHub issues but this is not a good model for the future. Instead, the swim lanes of Pivotal Tracker, Trello, Waffle, and ZenHub serve as good models for thinking about how we can redesign posts.

Like many of the other large feature ideas here, I don’t have specifics yet. I need to circle back and do some wireframing to get your thoughts. Then I can do some higher-fidelity designs and we can start tackling this piecemeal.

The general approach we need to take is to get working code into production progressively rather than doing a multi-month rewrite. We can layer functionality on top of what we have now. Stay tuned for a more actionable plan on this.

Add ability to assign tasks

We need to be able to point to someone who’s currently working on a task as the person responsible for it. This is pretty straightforward and you can see the relevant GitHub issue for it.

Add GitHub repos to projects and posts

When looking at the projects on Code Corps it’s hard to know where to dive into the code. The same goes with posts.

Here’s a GitHub issue for projects and here’s another GitHub issue for posts.

Add email onboarding for users

When coming into Code Corps for the first time, we don’t really communicate with you much. We have Intercom set up, but some of our onboarding should also happen in-app where possible.

This goes double for projects on Code Corps. It would be great if projects have a way to get new contributors up to speed on where to help. Our onboarding can direct them to relevant GitHub repos based on their skills. It can guide them to documentation that matters to them. It can show them a few quick tasks to get started on. And it can follow up over time.

There’s no task in GitHub yet, but we can start tackling this piece by piece. Verifying emails and adding transactional email templates are both on GitHub and would be good places to start.

Add project goals to projects

It’s hard to get a big picture view of what the whole team is working on when looking at tasks. Project goals can communicate both what we want to build and what potential supporters are helping to fund.

There’s an open GitHub issue for this here.

Add project updates to projects

Updating people about progress in the project is a requisite for getting everyone on the same page. It can help contributors feel good about the progress they’ve made and know what’s next. It can also help donors stay tightly connected to where their money is going. Have you ever donated to a charity and wondered where it went?

We have a basic GitHub issue for this here.

Add GitHub authentication

We need to add the ability to auth with GitHub as a first step to wider GitHub integration. Here’s the relevant GitHub issue.


Connect GitHub repositories to projects

As a next step, we can add GitHub repos to projects with the API. This is functionally different from the step above in that it’s not just using manual URLs, but actually authorizing the API itself. Here’s the relevant GitHub issue.

General organization

Now that the general plan is clear, let’s go over some organizational details. If you want to skip around, you can:

Slack: let’s talk in public
How my own role is changing
Become a team leader

Slack: default to public

We should try hard to transition from private to public messages. Here’s how we fared recently:

Code Corps Slack private vs public messages

That is way more private messages than public. Slack also told me:

The most talkative member of your team last week was you, with 2,321 messages. Nice work, team leader!

No, Slack! This is not okay!

But it’s not Slack’s fault. This is my failure. When you onboard to Code Corps, I’ve relied heavily on personally reaching out to you. This sets the culture and becomes the default way of talking. Who could blame you?

Talking in public means that everybody gets to learn what we’re learning. It also means people see progress being made. Progress isn’t measured just in pull requests and deployments. Progress also looks like shared understanding. That’s much harder to achieve in private.

We should try hard to talk in public wherever possible. If something truly deserves to be private, we can take it offline. But most of the private conversations we’ve been having? We both know they probably could have been public.

Sage vs prophet

One problem with our over-reliance on private messages is that it marks a leadership style that’s best described as the difference between a sage and a prophet.

The sage has been around forever. They’re wizened by age. They’re in the back corner of the office and have been there for a decade, maybe more. No one’s been around longer than them to say for sure.

Everyone goes to the sage with their questions. They know all the ins and outs of how things work. Everything you’re about to do, they’ve been there, done that. They’ve seen some things.

But a sage doesn’t scale. We’re at more than thirty contributors now. There are almost 90 people in our Slack and it’s growing almost daily. The sage is not a very good community organizer.

This is the time the sage has to transition into the prophet. The prophet sets the vision, sets the tone, and imparts new ideas. The team can take those ideas and run with it, but the prophet is not a single point of failure to the organization.

This post, hopefully, is an example of what that transition looks like. If you’re reading this, you know where everyone stands and what the plan looks like. You may still have questions, but at least you have a foundation.

Team leaders

Having a prophet to lay out vision is not enough. A prophet who leads a flat organizational hierarchy is destined for failure.

Compare this to efficient command and control structures we have in the Army: the Company Commander works with their Executive Officer (XO) and First Sergeant (1SG). The XO communicates with other XOs in sister units and higher. The Commander communicates up to their Battalion Commander and down to their Platoon Leaders (PLs) and 1SG.

The real backbone of the Army, though, is our Non-Commissioned Officers (NCOs). And our workhorses are our Soldiers. The NCOs like the 1SG, the Platoon Sergeant (PSG), and Squad Leaders take on the lion’s share of executing on the vision of the Commander. And the Commander is just passing along the vision of the Battalion Commander, and their Brigade Commander, and so on, all the way up to the President of the United States.

Ambush Army Squad

Code Corps is significantly smaller. Right now, we’re more like a squad with a few teams. And we need team leaders!

If you think you could step up and handle some minimal coordination of other contributors, then we’d love your help. We don’t think it will take much of your time or energy, but would go a long way to helping organize our efforts. You’ll also get a ton of support from myself and Nikola. Just reach out to us on Slack if you’re interested.

Share your thoughts

This was a long post, so congratulations if you read everything!

We would love to hear your thoughts on direction. Obviously feel free to discuss here, on Slack, or on GitHub.

Enjoyed this post?

Our best content on open source, social good, and building products. Delievered each week for free.