forked from CodeForPhilly/gettingstarted
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request CodeForPhilly#12 from lottspot/outline/starting-a-…
…project Provide base sections in starting-a-project.md
- Loading branch information
Showing
1 changed file
with
123 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,123 @@ | ||
## Roadmapping | ||
|
||
#### In a nutshell | ||
|
||
Roadmapping is the process of establishing one or more concrete, achievable goals and | ||
laying out each of the tasks which must be completed in order to accomplish each goal. | ||
To have a useful roadmap, it is important that these goals and the tasks which need to | ||
be done to accomplish them are explicitly documented, and easily accessed by all members of the team. | ||
|
||
It is important that the tasks which compose a goal in a roadmap be tracked; It should be | ||
known at all times whether or not a task is completed, if it's actively being worked on, | ||
and who is working on it if it is. | ||
|
||
Examples of good roadmap goals: | ||
|
||
- Implement a MVP | ||
- Implement all API endpoints | ||
- Complete 5 user tests | ||
|
||
Roadmap goals to avoid: | ||
|
||
- Complete the project | ||
- Find users for user testing | ||
|
||
#### Why Bother | ||
|
||
Like any other activity which demands time and effort from the team members of a project, it is important | ||
to understand the value prospect of roadmapping. This section describes some of the important and tangible benefits of roadmapping a project. | ||
|
||
###### Make work distributable | ||
|
||
When a goal is broken down into a step-by-step process which is accessible to the entire team, | ||
then each team member can take on a step, allowing multiple steps to be worked on by different | ||
people at the same time. | ||
|
||
###### Make onboarding simpler | ||
|
||
When the current project goal and the tasks is consists of are documented, it becomes simpler to | ||
take on new contributors. New contributors can simply be pointed to the location in which all of | ||
this information is documented, and select a task to begin working on. This simplicity lowers | ||
the barrier of entry for people to get involved with a new project. | ||
|
||
###### Make project progress trackable/measurable | ||
|
||
Documenting the tasks which need to be accomplished to fulfill the current project goal is the | ||
first step toward having a process for documenting the in-progress and completion status of each | ||
such task as well. This allows for a concrete measurement of progress toward a goal; how many tasks | ||
are done vs how many are not can help quantify how close the team is to accomplishing the overall goal. | ||
|
||
###### Make collaboration easier | ||
|
||
When individual tasks are being tracked as part of a roadmap, this makes it easier for teammates to | ||
collaborate. Teammates can avoid duplicating effort by knowing who is working on what, and have a shared | ||
understanding of what needs to be worked on next. | ||
|
||
## Onboarding | ||
|
||
#### In a nutshell | ||
|
||
Onboarding is the process of taking a potential new contributor from the point of knowing nothing about | ||
your project up to the point of making impactful contributions. As an open source project to which people | ||
donate their time, it is important to set reasonable expectations around contributors; many will come and | ||
go over the lifetime of a project. Because of this reality, it is important to keep the barrier of entry | ||
to new contributors as low as possible. | ||
|
||
#### Doing it successfully | ||
|
||
###### Simple introspection into current project status and tasks | ||
|
||
It is important that a new contributor can easily view the current project status, and determine from | ||
the current status of the project which tasks need to be done but are not currently being worked on. | ||
This provides a direct path for a new contributor to know how to become immediately helpful to a project. | ||
This is a need which can be met by establishing and maintaining a project roadmap, with tracked tasks. | ||
|
||
###### Clear, concise, up-to-date instructions on getting started with development (on all platforms!) | ||
|
||
All projects should provide instructions on how developers can setup their local machines to start | ||
working on the project. It is important that instructions exist **for every major platform** (Windows, OS X, Linux); | ||
every individual has their own preferences, and excluding platforms which your current team does not | ||
prefer alienates potential contributors. This should be done on a best effort basis; if no one | ||
on the team has access to a Windows license or to a Mac Book in order to provide instructions, then | ||
it simply cannot be done. | ||
|
||
What's perhaps most important about this point is that projects should avoid incorportating platform | ||
specific workflows into the development process (e.g., requiring batch scripts or AppleScript as part | ||
of the development process). | ||
|
||
###### Documented code base | ||
|
||
The code base should have comments on all methods and functions, and before any sequences of difficult | ||
to read or unusual code. This is a general coding best practice, but is highlighted in this context | ||
because of its impact on the ability of a new contributor to quickly become familiar with the current | ||
code base (and therefore more quickly make meaningful contributions) | ||
|
||
###### Human contact! | ||
|
||
Always be available to potential new contributors to ask questions, or even proactively reach out to | ||
them to try to help them find tasks to work on! The best documentation in the world is still no | ||
substitute for old fashioned human contact and communication. Contributors usually join projects | ||
to feel like they're working with a group of people to accomplish something. | ||
|
||
## Keeping up momentum | ||
|
||
#### In a nutshell | ||
|
||
Keeping a project moving forward is important; having a sense of progress keeps team members invested | ||
and gives the project the best chance of actually launching. This section covers some tips on helping | ||
to continuously foster a sense of progress in a project. | ||
|
||
#### Regular check-ins | ||
|
||
Have team members regularly report the current status of tasks they are working on. Not only does this | ||
help each team member motivate themselves to have progress to show, but it also gives the team insight | ||
into when a team member may need help with a task, or no longer has time to continue working on a task. | ||
This transparency also helps ensure that task and project statuses remained up to date, and reflect the | ||
actual state of the project. In addition to helping foster a sense of ongoing progress, this helps with | ||
things like new contributor onboarding and roadmap tracking as well. | ||
|
||
#### Goals and Deadlines | ||
|
||
When establishing roadmaps, set target dates for each step in the roadmap. Constraining goals to | ||
be accomplished by a certain deadline helps set a pace for progress on the project, and can provide | ||
that sense that the project is continuing to move stadily forwad. |