diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/project.md | 15 |
1 files changed, 11 insertions, 4 deletions
diff --git a/docs/project.md b/docs/project.md index a710eb1b..9e0db20b 100644 --- a/docs/project.md +++ b/docs/project.md | |||
| @@ -1,14 +1,14 @@ | |||
| 1 | # Why? | 1 | # Why? |
| 2 | This project started with the aim to produce a product that doesn't cater to all usecases, but does what it does well. | 2 | This project started with the aim to produce a product that doesn't cater to all usecases, but does what it does well. |
| 3 | We want a codebase that is well maintainable by a small team, and that can move fast. | 3 | We want a codebase that is well maintainable by a small team, and that can move fast. |
| 4 | We want a codebase where it is fast and easy to prototype new features and turn them eventually into full implementations, without compromising the quality of the rest of the system. Additionaly the product should be portable accross a variety of platforms, including mobile, not only due to a portable codebase, but also due to different interfaces for the various formfactors. | 4 | We want a codebase where it is fast and easy to prototype new features and turn them eventually into full implementations, without compromising the quality of the rest of the system. Additionaly the product should be portable accross a variety of platforms, including mobile, not only due to a portable codebase, but also due to different UI's for the various formfactors. |
| 5 | 5 | ||
| 6 | Because no existing codebase fullfills those premises or easily allows to reach them, this project started. | 6 | Because no existing codebase fullfills those premises or easily allows to reach them, this project started. |
| 7 | 7 | ||
| 8 | 8 | ||
| 9 | ## Differentiators | 9 | ## Differentiators |
| 10 | In order to avoid simply replicating what's already existing it's important to know how this product differentiates to other existing solutions. | 10 | In order to avoid simply replicating what's already existing it's important to know how this product differentiates to other existing solutions. |
| 11 | This section is supposed to outline that | 11 | This section is supposed to outline that. |
| 12 | 12 | ||
| 13 | * To Roundcube Next | 13 | * To Roundcube Next |
| 14 | * Native application | 14 | * Native application |
| @@ -53,7 +53,7 @@ Team Members: Michael Bohlender, Sandro Knauss, Aaron Seigo | |||
| 53 | 53 | ||
| 54 | It's the team leads responsibility to: | 54 | It's the team leads responsibility to: |
| 55 | 55 | ||
| 56 | * Organize regular online meetings (medium yet unknown) | 56 | * Organize regular online meetings (so far on google hangouts) |
| 57 | * Give direction to the product and ensure it's followed | 57 | * Give direction to the product and ensure it's followed |
| 58 | * Direct development and oversee decisions | 58 | * Direct development and oversee decisions |
| 59 | * Ensure documentation of decisions | 59 | * Ensure documentation of decisions |
| @@ -66,10 +66,17 @@ Should the team not be able to reach consensus, the team lead makes the final de | |||
| 66 | NOTE: We should probably have a phabricator board for open decisions. | 66 | NOTE: We should probably have a phabricator board for open decisions. |
| 67 | 67 | ||
| 68 | ## Planning | 68 | ## Planning |
| 69 | All planning happens on the KDE Phabricator instance: https://phabricator.kde.org/project/view/43/ | 69 | All planning happens on the [KDE Phabricator instance](https://phabricator.kde.org/project/view/43/). |
| 70 | 70 | ||
| 71 | ## Releases / Milestones | 71 | ## Releases / Milestones |
| 72 | Releases will follow achieved milestones. Milestones are assembled from tasks on the roadmap. | 72 | Releases will follow achieved milestones. Milestones are assembled from tasks on the roadmap. |
| 73 | 73 | ||
| 74 | ## Versioning | 74 | ## Versioning |
| 75 | The product will follow the semantic versioning scheme (semver.org), with each feature release corresponding to a milestone on phabricator. | 75 | The product will follow the semantic versioning scheme (semver.org), with each feature release corresponding to a milestone on phabricator. |
| 76 | |||
| 77 | ## Git repository | ||
| 78 | The git repository can be found here: [git://anongit.kde.org/kontact-quick](git://anongit.kde.org/kontact-quick) | ||
| 79 | |||
| 80 | The "development" branch is used for the latest development version, master is always stable and always releasable. Branches for specific versions that receive patch releases may be created as required. | ||
| 81 | |||
| 82 | For new developments use feature branches prefixed with "feature/" or simply use the "git flow" tool. | ||