FANDOM


CLS 13 - Day 1 (Saturday, July 20) Session 5 (4:30pm-5:30pm)

Strategies for onboarding new developersEdit

Attendees:Edit

  • Shelley Hostetler – Oclc – Community Manager, WorldShare Platform
  • Alexis Smecher – Public Knowledge Project – Technical Architect
  • Jason Yee – Opensourcery – Developer
  • Daniel Duvall – National Novel Writing Month – Technical Director
  • Sara-Jayne Farmer – Devdat – Consultant
  • Sarah White – Asciidoctor Project – Content Strategist
  • Ross Turn - InkTank
  • Michael Hunger – Neo Technology – Developer Evangelist
  • Angela Oduor – Ushahidi – Community Developer Liaison
  • Ward Pifer – Fidelity Investment – Product Manager of Stretegic Services
  • Jeffrey Taylor – Bemyapp – Head of Events
  • Jeff Potts – Alfresco Software – Chief Community Officer
  • Daniel Hinojosa – Slashdot Media – Community Manager
  • Jason Cameron – Morenet, University Of Missouri System – System Administrator
  • Andy Oram – O’Reilly Media – Editor
  • Eric Schultz – Outercurve Foundation – Developer Advocate
  • James Falkner - Community Manager - Liferay (Topic Organizer)

DiscussionEdit

Starting pointEdit

Assumption: developers want to join your project - look at how the website looks to them.

Question: How do you know when one is onramped? A: when they can contribute enough to a c++ ceph thing. When Developers are on first approach: the ‘heres how you get started’ path should be clear.

Onramp has 2 aspects: one is the technical aspect: “what is the information I need to get going.” the other is the personal angle. it’s easier to onramp if you have people to onramp because you have other people that are willing to answer questions.

Mozilla Onramp example: New devs are presented a page, and if they want to get involved, what are their skills? They fill it out like a wizard. it matches the skills with the potential. You can then pick easy bugs to fix, or harder things in your ‘area’ that involve a mentor.

There is also research says: new developers should get a reward within 2 hours. Mozilla aims at this. Ubuntu/Liferay also have a 100papercuts (irritating, but really easy bogs). Some projects even leave easy bugs open just for this purpose (the chum bucket).

Neo4J: We generate tests based on example code in the documentation - if the API changes, documentation “breaks”, and the build fails. Ensures docs are always accurate, good for onramp activities.

Documentation is important: People cut/paste from the docs all the time. All the knowledge is in devs heads, so its best to write it down. Docs are super important.

The project with the better docs (but not best design/code) will win over other perfect platforms. They will attract and retain more devs.

Question: getting ppl onboard is one thing, but to bring someone onboard you have to have criteria before they join, like, do they have matching skill sets for what’s needed in the project? If they don’t, then you waste time educating people.

Counter-argument: it’s actually a bad idea - people aren’t going to give you complete crap, and worst case you can do is reject it because whatever they contribute won’t work. biz people do this a lot.



Our project on-ramps 3 types of people: 1) random strangers, 2) institutional developers or support ppl, and 3) people we are hiring. We’ve never been able to hire someone with no experience and succefully on-ramp them. Why? Not sure, but possibly because we are distributed. They are on their own for 2 weeks, and often get frustrated and give up and never show back up.

What is the motivation for new developers?Edit

This is a key part of on-ramp - without motivation, people won’t stick through it. In Liferay’s case, motivation isn’t monetary - people want more time in the day, more knowledge, and special privileges/powers on website (top 3).

Other motivations:Edit

Recognition in the community.

One developer that cares and is passionate about learning and doing things right is better than 5 developers who want squeezy balls in the mail for their bugfixes.

For the “lack of time” - there is a solution: do things like sprints after or before an event, or a hackathon during training where experienced developers would not want to attend training, and would otherwise have nothing to do during that time. But, the cool thing is this lmost always attracts new developers. And the reward is sitting in person with rock stars.

Very successful projects - why are they successful and have lots of devs? because they are de-coupled, modularized. You can insulate your issue, and work independent of the rest of the code base, without worrying your change might have collateral damage. Also, bringing new devs up to speed in a modular project is much easier, as they can concentrate on their module (s).

Most open source is designed like a business, with interfaces between departments. At least that’s the ideal case.

What are some characteristics of projects which attract and can train developers quickly?Edit

  1. Good docs (for project developers AND for developers of implementations using the project)
  2. easy to get your work seen (recognition)
  3. easy to install / run / test / debug (cycle should be short)
  4. modularlizability
  5. Good developer tools - that default to permissiveness
  6. Good commuity (mailing lists, forums, stack overflow, etc)

Question: what if you’re developing an API or web service? then you need a sandbox to play in to quickly prototype/test things. example: hydra console (JSON WS exerciser).

Competitions: They really work! You don’t necessarily have to have a competition, but just a ranking or top leaderboard.

Office Hours (e.g. a bi-weekly google hangout): a very difficult one to support. We’ve been doing it every couple of weeks with varying success.

Alfresco: at our events, we have “engineering office hours”, with a big board of engineering leads, their pic, bio, and people at the conf can sign up for 1:1’s.

Other projects: we do contributor spotlights: what this contributor did for the project.

Mentors: how to find them? You have to ask them, or they come to you - people really have to be dedicated.

SummaryEdit


Top tips of what NOT TO DO for attracting/training/retaining devs:

  1. ignore submitted patches
  2. Treat community members bad
  3. immediately reject bad patches (instead, work with them to fix)
  4. Rewrite patches without explanation
  5. Let things just sit and fester

Top tips for onboarding new developers:

  1. Have Good Docs
  2. Have Working Samples
  3. Know what skill sets before setting new devs off on their tasks
  4. Ensure availability of seasoned pros
  5. Properly motivate (find out what community wants - money? fame? CV enhancement?)
  6. Initial Welcome is very important

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.