The Chaos Toolkit aims at being a unifying automation protocol for Chaos Engineering experiments.
This document covers core projects only:
- the Chaos Toolkit CLI
- the Chaos Toolkit core library
- the Chaos Toolkit bundler
- the Chaos Toolkit documentation
- the Chaos Toolkit governance efforts
For any extensions, please see each related project for their own roadmap.
An open-source project starts small but, as it grows, becomes more difficult for its community to follow, or help with. In the case of the Chaos Toolkit, over the years, new issues were raised that had great potential. They were referenced in a meta-issue, the infamous Paving the way for greater and more powerful automation. This issue became a bit of a mess and wasn't really helpful to understand what was worked on ot not. Eventually, @ojongerius suggested we should setup a more formal roadmap so that community could start helping as well.
A roadmap is here to make visible the path to the future of the project. It supports better governance and a more active contribution dynamic.
The Chaos Toolkit is an open project with a semi BDFL approach. The idea is not for the project maintainers to veto randomly but to provide support and guidance by keeping the project consistent with its original values and goals, while moving forward.
As for June 2020, there is no heavy process around this governance. This is to say that the project evolves based on its community requirements while gradually building a proper definition of its own future.
Glad you ask! The Chaos Toolkit is an open source project which strives to be welcoming and supportive of contributions. we love a civil and joyful community that respects its members. To help the project you have a variety of entry points, depending on your experience and time. With regard to the core, we'll do our best to keep this roadmap up to date so that you can quickly see if anything picks up your interest. In that case, mostly start by creating and issue and come to the community chat to announce it. Usually we expect PRs with fully squashed and signed commits.
Not everything is part of the roadmap because not everything in life can be planned ahead. Therefore, expect issues and features to be worked on at any time.
With that said, there cannot be visibility without some sort of planning either. To be a little more dynamic and visible, this project relies on GitHub project boards. For now these are the existing projects:
- https://github.com/orgs/chaostoolkit/projects/5: This is an org-level covering all the core repositories listed above.
As the Chaos Toolkit grows, new boards will likely come to life but until then it feels more connected to have a single one.
Any issue of these repositories could be part of the roadmap, just ensure they are associated with that project to become "actionable".
A roadmap item is not a particular issue. It's merely one that moves the project forward as it matures. Bugs can become roadmap items if they demonstrate a current limitation that could be unlocked with an improvement of the core projects. So can feature requests.
It may take some time before anything enters the roadmap:
- go through a first review to determine what the issue/question is about
- see how it fits into the project's goals. Sometimes a feature request makes sense on its own but gos beyond the scope of CTK
- consider its efforts at first glance
Once entered the roadmap, timing can be discussed to see when any work is done on it.
This may look like a convoluted and fairly loose way to organise the project but the idea is to offer a visibility on how things can move forward.
As ever, don't hesitate to come to the chat to discuss this with the maintainers and community. The whole "process" will evolve and improve.
In an ideal world, there would be milestones. We think we will get there someday with a more regular release scheduling, like every 6 month or something in that vein.
For now, the project is not structured well enough to make any sort of promises as to when new releases happens.
However, milestones could be used to advertize of future releases scope, so they prove useful. The only downside of GitHub milestones is that they only exist on a per-repository basis, which lead to more project maintenance.
Nevertheless, we will be using milestones to scope a future release but without a release date in mind for now.
In this section, we will link to future milestones so that can be easily discovered.
- command line flags to pass variables as a file or directly via the cli #175
- enable steady-state execution strategies
- add a command to the cli to set properties in the settings file #65
- enable extending secrets backend #114
- improve
discoverandinitcommands to make them more useful/usable - improve json format logging #173
- improve documentation
- create an official repository/package of common tolerances
- create an official repository/package for common controls
- add a flag to control the rollbacks strategy #176
- support finer control over rollbacks and when they should be executed #177
- the notification API in favour to more specific internal events
- archive chaosplatform projects and move them to the attic
To be defined :)