blog

archives

The Discourse Encouragement Fund

Erlend Sogge Heggen February 16, 2017

For almost a year now, we’ve been doing something that’s considered quite risky for an open source project: Paying contributors. Communities like ours are fundamentally built on intrinsic motivation. Getting money involved can jeopardize the whole ecosystem, but for the past year we’ve been experimenting with a model that lets us pay contributors for mission-critical work, while maintaining a culture of volunteerism.

It all started with the Mozilla Open Source grant* about a year ago. This grant effectively enabled us to pay our own developers to work on features that were strategic to our business, as long as these features were also aligned with the “common good” mission statement set forth in our MOSS roadmap (which was to improve our email capabilities). So with some of our company’s developer time being paid for by this grant, we decided to pay it forward by using an equivalent amount of our own money on some more experimental ventures for developers from our community to take on.

To date we’ve paid 16 different developers a total of $17’000 to work on bite-sized tasks. All of the work is open source, and two of the developers we’ve worked on paid assignments with are now core members of our team!

A process for rewarding contributors

For the past year, we’ve been fine-tuning the process of handling paid contributor work. These are the key lessons we’ve learned:

  1. Define a rough spec. A one-pager with bullet points, posted as a public discussion topic on meta.discourse.org, would usually suffice. The important part is to move past any implementation controversy. Unlike in-house development where we sometimes start work while the spec is still being defined and talk, argue and finally agree through code, this is not ideal for outsourced work. The spec can still be rough as long as there is 100% consensus on the key ideas among the core developers.

  2. Make it a bite-sized task. All tasks pay between $150-$1000. Any less and it’s usually better to leave it as a pro-bono contribution opportunity. Any more and it’s gonna become a project (i.e. dependencies, deadlines) instead of a one-off task.

  3. No hourly rate. A fixed fee simplifies the transaction. We say “would you be interested in doing Task-X for Y$?”; the contributor assesses the scope; after cutting out a couple stretch goals we’re in business. This payment is not so much a freelance assignment as it is an acknowledgement of a valued contributor.

  4. We choose who, what and when. At first we tried to put tasks “up for grabs”, but this method didn’t work too well. You end up with multiple takers and you have to pick one and let others down. Instead, we approach developers individually, one at a time. Since we’re an open source project we know fairly well who’s capable of what, so we’ll tap our top prospect, present the task & “bounty”, and get a yes or no. If no, we move on to the next good prospect. If we run out of good prospects for a specific task, we’ll either do it ourselves or put it on hold.

  5. Tasks are mostly strategic. As in, directly or indirectly, this improvement is gonna save or earn CDCK Inc. money. This is the easiest way to draw a line between “what type of job deserves funding?”

  6. Tasks are mostly time insensitive and free of dependencies. Doesn’t really matter to us if it’s done tomorrow or next month as long as it gets done. It’s not a good idea to expect part-time contributors to jump on to the speeding train that is core development.

  7. Spread it out. We’ve tried to not play favorites. Most volunteer contributors appreciate the opportunity to work closely with the core team at a more professional level – as do we with them – so we want to have that experience with as many regulars in our community as possible: programmers, designers and technical writers alike. What’s more, as a sporadic call-to-action it doesn’t appear to disrupt the give & take spirit of open source volunteerism.

This is a process that will continue indefinitely, as we are extremely happy with the outcome for both our product and community.

For a long time this was just something we were doing, but eventually it became “The Discourse Encouragement Fund”. As much as we’d like to, we can’t put every one of our contributors on a steady payroll. What we can do is remind them that the work they’re doing is valuable, in every sense of the word, and that there is money to be made from specialising in Discourse. For the truly committed, the opportunities are out there. A bigger ecosystem benefits us all, so if you’re entertaining the thought of generating a steady income through Discourse work, we’d love to talk about it.

p.s. we recognise that having the time to volunteer in the first place is a privilege. In conjunction with the Encouragement Fund, we are also experimenting with contracting gigs and paid internships, but that’s a different post for another time!

8 comments

Discourse New User Tips and Tricks

Jeff Atwood December 16, 2016

If you’re new to Discourse, here are a few quick tips and tricks to get you started:

Reading

Selecting a topic title will always take you to your last read post in the topic. To enter at the top ↑ or bottom ↓ instead, select the reply count or last reply date.

topic list click areas in Discourse

Topics above the light red line are new or updated since your last visit. If you have read all the way to the end of a topic, its title will be light grey instead of black.

last visit date shown on topic list in Discourse

Navigation

For search, the menu, or your user page, use the icon buttons docked at the upper right.

search, menu, and notifications in Discourse

While reading a topic, use the timeline on the right side to jump to the top, bottom, or your last read position. On smaller screens, select the bottom progress bar to expand it.

(If you have a physical keyboard, you can also press ? for a list of keyboard shortcuts.)

Replying

Press any Reply button to open the editor panel at the bottom of your browser. Continue reading (and even navigate to different topics) while you compose your reply; minimize the editor for more room. Drafts will automatically be saved as you write.

collapsing and expanding the editor in Discourse

To insert a quote, select the text you wish to quote, then press the Quote button that pops up. Repeat for multiple quotes.

selecting a quote in Discourse

To notify someone about your reply, mention their name. Type @ to begin selecting a username.

mentioning a username in Discourse

To use standard Emoji, just type : to match by name, or traditional smileys ;)

completing Emoji in Discourse

To generate a summary for a link, paste it on a line by itself. To start a topic with a link, paste the link into the title field.

pasting link to onebox in Discourse

Your reply can be formatted using simple HTML, BBCode, or Markdown:

This is <b>bold</b>.
This is [b]bold[/b].
This is **bold**.

For more formatting tips, try our 10 minute tutorial.

Actions

There are action buttons at the bottom of each post:

  • To let someone know that you enjoyed and appreciated their post, use the like button. Share the love!
  • Grab a copy-pasteable link to any reply or topic via the link button.
  • Use the button to reveal more actions. Flag to privately let the author, or the site staff, know about a problem. Bookmark to find this post later on your profile page.

Notifications

When someone is talking directly to you — by replying to you, quoting your post, mentioning your @username, or even linking to your post, a number will immediately appear over your profile picture docked at the top right. Select it to access your notifications.

notification in Discourse

Don’t worry about missing a reply – you’ll be emailed any notifications that arrive when you are away.

Preferences

All topics less than two days old are considered new, and will show a new indicator.

new topic indicator in Discourse

Any topic you’ve actively participated in — by creating it, replying to it, or reading it for an extended period — will be automatically tracked on your behalf, and will show an unread post count indicator.

unread topic indicator in Discourse

You can change your notification level for any topic via the notification control at the bottom, and right hand side, of each topic.

topic notification control in Discourse

Notification level can also be set per category. To change any of these defaults, see your user preferences.

11 comments

The ideal GSoC applicant

Erlend Sogge Heggen March 11, 2016

This is our first year participating in Google Summer of Code. In short, if you’re a student with some Rails & Ember skills, you should check out our GSoC profile and consider applying for a chance to do paid work on Discourse under the mentorship of the core team this summer. We’ll be taking applications during 14. – 25. of March. With that out of the way, we’d like to take a moment to explain what we’re looking for in a GSoC student.

student-banner

Since our admission into the GSoC program, we’ve already heard from a handful of students, and they all ask the same recurring question:

Should I contribute to the project before applying?

Talking to students so far we’ve been a bit hesitant to outright demand prior contributions. But truth be told, we would have preferred it if you contributed to Discourse yesterday.

When the applications start rolling in on March 15th, we’ll keep an open mind and sincerely consider all applicants, regardless of community involvement prior to GSoC. However, while an absolutely kick-ass application might still win through in the end, prior contributions is undoubtedly the best way to get to the top of the pile.

We’re not looking for drive-by contributors

If you see this through the lens of a job interview, it’s a big ask. Basically we want you to put in hours of free work just to have a shot at getting the paid position. That’s the wrong way to look at it though. We don’t think of GSoC as a part-time employment, we see it as a reward for your passion.

Google has gifted us with an opportunity to reward passion, just like Mozilla did with their MOSS grant and as we do ourselves when our budget allows it.

Over the course of a few years, my personal engagement with Discourse roughly went like this:

  • 100% passion work
  • 95% passion work, 5% paid work (one-off paid gigs)
  • 80% passion work, 20% paid work (some regular freelance gigs)
  • 20% passion work, 80% paid work (full time employment)

Most of the paid work I do now is the type of work I would readily do for free, but getting paid enables me to do way more of it. I was perfectly happy at all stages of my engagement with Discourse; which stage you’re shooting for is up to you. The point is, if your level of engagement with Discourse looks like this:

  • 0% passion work, X% paid work

Then we’ll have a hard time working together. We’re just not cut from the same cloth. We’ll have a hard time understanding one another’s drive and motivations. Most critically, we’re not passionate about the same thing.

Are you passionate about Discourse? Please consider applying for one of Discourse’s projects in GSoC 2016!

4 comments