Traditional project management systems are designed to solve organizational problems - that is, problems that occur when trying to be productive in organizations of collaborators. As a result of this, they tend to be focused on stable, live projects and be unsuitable for Projects that are undergoing iterative, experimental creation, or for Projects that don't have a fixed end-point in mind, or for Projects for which the stable release represents the end point, rather than the starting point.
This system is designed to be more flexible - to give a conceptual rigor and structure to more experimental, iterative or creative Projects. Because of its flexibility, this system can be a meta system, with more traditional organizational methods living within it. For example, a Scrum Sprint could represent a single 🛠️Elaboration Effort, or a month of Kanban could represent several concurrent 🩹Stabilization Efforts. More on these terms later!
The system was designed with solo-developers in mind, but because Efforts can be concurrent and because the system is only fuzzily opinionated, it should work fine for teams as well.
- All creative work is organized into Projects (even a two-hour test that's never worked on again!)
- Energy spent working on Projects is organized into Efforts, which can run concurrently
- All Projects start as a 💭Concept, then go through up to three Phases of development: ⚗️Experiment, then 📐Prototype and/or 💎Release
- Efforts represent three types of work - 🧪Experimentation, 🛠️Elaboration and 🩹Stabilization
- When Efforts complete, they change a Project's Version - so a Project's Version is an indication of its development history and indicates the type of its most recently completed Effort
- All Projects begin as a 💭Concept in somebody's mind. The 💭Concept phase is for Projects that have not yet had any work done on them
- No Efforts occur in this phase
- The Project's Version is
0.0.0
- The ⚗️Experiment phase is for Projects that have not yet reached an initial state of completion
- In this phase, all Efforts are 🧪Experimentation Efforts, and the Project's Status is always ⚗️Experiment.
- The Project's Version is
0.0.0-eX, where X is the number of completed 🧪Experimentation Efforts that have occurred - Each time an 🧪Experimentation Effort is completed, a choice is made. Has the Project reached some initial state of completion?
- If so, then the Project enters the 📐Prototype phase and its Version changes to
0.1.0- Alternatively, if it is felt to be justified, the Project can skip the 📐Prototype phase and move straight to the 💎Release phase, in which case its Version changes to
1.0.0
- Alternatively, if it is felt to be justified, the Project can skip the 📐Prototype phase and move straight to the 💎Release phase, in which case its Version changes to
- If not, the Project remains in the ⚗️Experiment phase and the experiment digit in its Version is increased (e.g.
0.0.0-e3->0.0.0-e4)
- If so, then the Project enters the 📐Prototype phase and its Version changes to
- The 📐Prototype phase is for Projects that are functional, but incomplete, in-progress, unstable, or otherwise not ready for public use/viewing/etc.
- The Project's Version in the 📐Prototype phase is always
0.X.X-eX - In this phase, any of the three Effort types can occur, each having a different result
- 🧪Experimentation Efforts are for trying out new ideas in the Project that may or may not be completed, fully integrated or otherwise pursued. Upon the completion of 🧪Experimentation Efforts, the Project's experiment Version number is incremented and the Project is optionally marked 'Experimental' (e.g.
0.3.2->0.3.2-e1) - 🛠️Elaboration Efforts are for adding features that are relatively stable, when compared to Experimental features. Generally, at the conclusion of 🛠️Elaboration Efforts, the Project's Feature Version number is incremented (e.g.
0.3.2-e1->0.4.0) - 🩹Stabilization Efforts are for fixing bugs, making small tweaks, and otherwise doing little bits and pieces that don't really represent adding meaningful features. Generally, at the conclusion of 🩹Stabilization Efforts, the Project's Patch Version number is incremented (e.g.
0.3.2-e1->0.3.3)
- 🧪Experimentation Efforts are for trying out new ideas in the Project that may or may not be completed, fully integrated or otherwise pursued. Upon the completion of 🧪Experimentation Efforts, the Project's experiment Version number is incremented and the Project is optionally marked 'Experimental' (e.g.
- At any point in the Prototype phase, but often after the completion of 🛠️Elaboration or 🩹Stabilization Efforts, the Project can be considered in a sufficient state of completion, readiness, stability, etc. to justify it leaving the 📐Prototype phase. When this occurs, its Version number is set to
1.0.0and it enters the 💎Release phase.
- The 💎Release phase is for Projects that are functionally complete, or have reached some level of completion where they are ready for public use, exhibition, consumption, etc.
- Functionally, the 💎Release phase operates identically to the 📐Prototype phase
- At any point in the 💎Release phase, when deemed necessary and/or justified (but often after the completion of 🛠️Elaboration or 🩹Stabilization Efforts), the Project's Major Version number can be incremented (e.g.
1.3.2->2.0.0)
- WeekLog uses version numbers that are similar to Semantic Versioning (SemVer). There are four numbers in a Project's Version, with the structure
R.F.P-eE- R = Release
- Analogous to major version numbers in SemVer
- Represents a major set of new features, or an incompatible release of a publicly-used Project
- Is always zero during the ⚗️Experiment and 📐Prototype phases
- Can be incremented after 🛠️Elaboration or 🩹Stabilization Efforts, if deemed necessary and/or justified
- F = Feature
- Analogous to minor version numbers in SemVer
- Represents new features and improvements over the previous Feature version that are backwards-compatible
- Is always zero during the ⚗️Experiment phase
- Reset when the Release version number changes
- P = Patch
- Analogous to patch version numbers in SemVer
- Represents backwards-compatible bugfixes, tweaks and very minor improvements that don't represent any meaningful change in functionality
- Is always zero during the ⚗️Experiment phase
- Typically incremented at the conclusion of 🩹Stabilization Efforts
- Reset when the Feature or Release version number changes
- E = Experiment
- An additional number not present in SemVer
- Represents the number of 🧪Experimentation Efforts that have concluded since the last non-experimental version
- If zero, it is ommitted from the Version (i.e. there cannot be a project with a Version of
2.1.3-e0, it would instead simply be2.1.3) - Incremented at the conclusion of 🧪Experimentation Efforts
- Reset when any other version number changes
- R = Release
Obviously, creative Projects don't always evolve in accordance with rigid structures. All the rules set out in this document represent intended default behaviours that can be overridden. The only thing necessary to keep a Project within this structure is to set the correct Effort type when adding Entries into WeekLog.
However it's possible to arbitrarily change Effort types, Project phase, Project version, or anything else at any time without breaking the system. Feel free to give your own meanings and names to the different Phases, Effort types and Version numbers! Rather than 💭Concept, ⚗️Experiment, 📐Prototype and 💎Release, what about 🥜Seed, 🌱Sprout, 🌳Shrub and 🌲Tree? If you are a digital artist, perhaps the version numbers represent sketches, linework, shading and post-processing?