Considerinng Being a Project Lead?

Leading a project is a serious commitment but a very rewarding experience. If you're trying to decide whether to be a project lead, please read the following documents:

• Google Summer of Code (GSoC) mentor guide
• Outreachy mentor role description, mentor expectations, and mentor FAQ

If you'd like to be a project lead but don't have a specific project in mind, email the CC Developers mailing list and let us know what your skillset and availability is. We'll see if we have a project you can help out with. If you'd like to propose a project, read on.

Proposing a Project

If you'd like to propose a project for a contributor to work on, please use the following template and send your idea to the CC Developers mailing list. Someone from CC staff will get back to you about whether it is a viable project and next steps for moving it forward.

[Project Title]

• The Problem: Describe the problem that needs to be solved and why it is an important one for CC.
• Expected Outcome: Describe the outcome that you’d like to see for this work program.
• Contributor Tasks: What will the contributor be expected to do during the work program?
• Application Tips: What are you looking for in the contributor’s project plan in their application?
• Resources: List of resources associated with this project idea. GitHub issues, specs, documentation. blog posts, etc.
• Project Lead: Who will be the project lead on this project?
• Technical Skills: What technical skills will this project need?
• Difficulty: How technically difficult is this project? Options: High, Medium, Low
• Size: Options: Large (~350 hours) or Medium (~175 hours).

Please note that project ideas should be related to an existing CC open source project or website and should be clearly scoped out. They should be doable in three months by a contributor with very little prior experience.

Application Period

Once the initial application period opens, things get chaotic for a little bit as hundreds of applicants investigate various open source communities to try and contribute to them and find a good fit for a work program. There are a lot of emails, Slack messages, GitHub comments, and so on. This stage of the program is the most intense and lasts about a month (although the first few days are the most overwhelming).

Some tips:

• Be prepared for this ahead of time.
• Have a good, well-documented set of tasks suitable for first-time contributors that you can point people to.
• Point people to public channels and away from email and DMs so that others can answer questions too.
• You will get a lot of low effort questions like "how do I get started" – ask for more details. You cannot spend 20 minutes helping every single person because there are far too many people, so help them help themselves.
• Prepare general documentation/frequently asked questions ahead of time.

Draft Application

You should encourage applicants to share drafts of the application with you ahead of time. Using a Google Doc with comment permissions enabled is probably the easiest way to achieve collaboration. Focus on making sure that their understanding of the project, the project plan, timeline, and deliverables match what you had in mind and is feasible (keeping in mind that they may be new to all this and may not get things done as quickly).

Work Program Period

Preparing

Before the work program period begins:

• Talk to your backup lead ahead of your time to create a plan for how to collaborate:
  • Who will be repsonsible for what?
  • How will checkins and notes work?
• If your project affects or involves anyone else at CC that's not leading the project, talk to them about how they would like to be involved and come up with a plan to collaborate.

Post-Announcement

Once the selected contributors have been announced:

• Reach out to your contributor ASAP.
• Get the contributors’ t-shirt size and address ASAP and send it to the program coordinator (we try to send out CC goodies).
• review the proposal again and ensure that the implementation details and weekly deliverables are feasible and well thought-out. there are probably some things that could be clarified or changed – work with the contributor to fix these items before any work is actually started.
• have an introductory call with the contributor and get to know each other. ask them questions about themselves and talk about yourself too.
• set up regular meetings: a weekly video call for the project lead to check-in with the contributor, and a monthly call with the cc program coordinator to check in with the contributor.
• create a document to keep any project information and notes. this document should be shared with the program coordinators.
  • the “final” implementation plan and weekly milestones (“final” because it is subject to change during the coding period based on progress)
  • the contributor’s contact information and emergency contact
  • all meeting notes
  • any other project-relevant information.
• decide with the contributor on the workflow the project will follow. e.g.
  • does the contributor understand regular git workflow (e.g. pull requests, branches, reviews)?
  • how often should code be reviewed? does all code need to be reviewed?
  • how often should code be committed? does all code need to use pull requests or can some be pushed directly to master?
  • will the contributor commit directly to the repository hosted on the CC GitHub or will they use a fork?
  • what is the best way for the contributor to get your attention when they are stuck?
  • where will their project be deployed (if applicable) during development?
• let the contributor know that they will be expected to post updates on their project on the cc technical blog regularly. decide on a cadence for the blog posts (should be every two weeks at a minimum) and set due dates for them.
• help the contributor get their development environment set up.
• ensure that the contributor has permissions to push to the appropriate GitHub repository.

During the Work Program

During the work program:

• Attend your weekly check-in.
  • Take good notes so that your backup lead can pick up where you left off easily if you’re unavailable.
  • Make sure the contributor is on-track with their weekly milestones and if not, work with them to figure out why and come up with a plan.
  • Ask how the contributor is doing generally.
  • Praise things they are doing well and provide constructive criticism on the things they could improve on. Both of these are important.
• Review all work/code promptly. You should aim to review within 1 business day.
  • If your contributor is blocked on their work for some other reason, help them become unblocked as soon as possible.
• Check in on Slack with the contributor once every day or two. Remember that they are often not experienced with the work they are doing and may not know to ask for help or may be stuck on something that they cannot articulate very well.
• Ask for feedback as the project lead every few weeks.
• Find an opportunity to invite your contributor to present their work at CC’s all staff meeting. It is up to you when you’d like to do this.
• Make sure you're familiar with the program timeline and submit your required evaluations on time.
• Engage the contributor in the larger CC development community. Encourage them to share their work and talk to them about other projects and your own work.
  • Ensure that the development version of their project is deployed somewhere ASAP so they can seek feedback from the community.
• Work with the CC staff engineering team and program coordinators on a plan to move the project to production when the project is complete.
• Check in with any CC staff working with the contributor regularly to make sure their feedback is also being heard and implemented by the contributor.
• Talk to the program coordinator proactively. Especially if:
  • your contributor is not active and engaged regularly.
  • your contributor is not communicating enough or misses a check-in.
  • you have concerns or even just a bad feeling about something.
  • you have feedback or questions about any part of the program process.
  • you'd like feedback about how your role as project lead is going