leogr
commented
1 year ago Dear @falcosecurity/core-maintainers :sunglasses: :mega:
As promised, I experienced a bit with GH projects and created one for our roadmap (consider it a draft since it is far from complete).
While doing that, I realized two things:
- The tool has a couple of issues (but I will talk about that later) :disappointed:
- We need a well-defined process :sweat:
For the latter, in the end, I wrote down an initial proposal :sweat_smile: :angel: (attached below). Please consider it more as an RFC rather than an actual proposal. I guess we will need a long trial and error before reaching our desidered state.
If you agree, the first step would be to schedule a call for the maintainers and discuss the roadmap.
Finally, I want to thank @jasondellaluce @LucaGuerra @Molter73 @incertum @Andreagit97 since, in our recent discussions, you provided me with valuable input and feedback in this regard. :pray:
Falco Roadmap proposal
This proposal is to use this GitHub project as the tool for the Falco Roadmap.
Scoping
The roadmap is intended for Falco releases only, but since Falco depends on several components, the scheduling and planning activities may span across several repositories. We assume at least all core repositories are somehow linked to the roadmap. Thus, the roadmap may include items from all the related Falcosecurity repositories as needed.
Scheduling
Falco gets released 3 times per year.
We allocate a 16-week period to each Falco release.
By doing so, in a year (52 weeks), we will have 16 x 3 = 48 weeks of scheduled activities, plus 4 weeks for breaks or quiet periods.
Each 16-week time frame is split into 3 different iterations, as follows:
| Iteration name | Duration | Description |
|---|---|---|
| Dev | 8 weeks | Development phase |
| Stabilization | 4 weeks | Complete features and bug fixing |
| Release prep | 4 weeks | Release preparation, testing, bug fixing, no feature |
The last week of the Release prep should end before the last Monday of the release month (Jan/May/Sept).
The last Monday is considered the targetted release date (when the git tag happens), and the rest of the week is assumed to be a break period.
Falco components
The release scheduling of Falcosecurity components that Falco depends on needs to be adjusted to meet these requirements. For example, a libs release may be needed one week (or sooner) before the end of each iteration.
Planning
Core maintainers are responsible for the roadmap of the overall project. During each iteration's first week, maintainers meet to review the planning and prioritize the ongoing workstreams.
With this approach, only 9 meetings per year are required (which is more efficient than a monthly call; still, further sessions can be scheduled as needed).
During the planning, items are assigned (or moved) to the current (or to a future) iteration (which represents the targetted due date for completing a workstream).
Testing and QA
The outcome of each iteration must include at least one Falco pre-release (or a usable dev build, TBD) intended for testing and QA purposes. It is acceptable for those builds to have incomplete features or known bugs, however, they must allow any community member to participate in the testing and QA efforts.
Since Falco strongly relies on libs, each of those Testing/QA releases must be based on the latest libs development for the target iteration. This also implies that each iteration's outcome must include a libs release (pre or stable).
The target time frame for those Testing/QA releases is the last week of each iteration (or sooner in the case of the Release prep iteration).
ewilderj
incertum
Andreagit97
LucaGuerra
Motivation
We want to manage better and give more visibility to the Falco Roadmap. We also need a more predictable process for our development cycles.
Feature
See the proposal draft below.
Additional context
This initiative was discussed several times during community calls and among maintainers. We recently completed a Falco release cycle, so it's time to bring up this again.
Updates:
/assign