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:
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