Closed leogr closed 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:
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:
This proposal is to use this GitHub project as the tool for the Falco Roadmap.
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.
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.
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.
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).
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).
- The tool has a couple of issues (but I will talk about that later) disappointed
One huge limitation is the inability to auto-add items from multiple repositories (:disappointed: the popup in the screenshot below :point_down: explain the reason behind that :moneybag: )
They can still be manually imported, but without automation may become a frustrating process. At the moment, I've no idea how to work around this.
In general, only some default workflows can be enabled (those in the screenshot), and there's no possibility to create a custom workflow :crying_cat_face:
without automation may become a frustrating process
is this something that Zapier could help with? https://zapier.com/apps/github/integrations
Truly love the proposal around testing and QA formality. We will be able to increase both stability and development speed.
Curious to hear everyone's feedback re how to best track high level goals for each release while staying flexible enough?
Perhaps, adding a doc to the repo to describe those high level goals and identify the corresponding (new) label could be a good way to do this?
Objectives and key results (OKRs) as goal-setting framework could be an option. Important would be to avoid unnecessary overhead while keeping the charm of open source (just open a PR).
Lastly, what about Jira + GitHub, w/ Jira automation enabled? CNCF ServiceDesk might be able to spin up a Jira instance for Falco. Happy to ask on behalf of the Falco community.
Perhaps, adding a doc to the repo to describe those high level goals and identify the corresponding (new) label could be a good way to do this?
I was thinking exactly about that. We already have a label roadmap (but, as you can see, it's rarely used) for that purpose. We can simply use it to define high-level goals, then iterate in GH projects. If used in combination with GitHub tasklists we can also easily track sub-tasks.
Objectives and key results (OKRs) as goal-setting framework could be an option. Important would be to avoid unnecessary overhead while keeping the charm of open source (just open a PR).
Not sure if all maintainers are familiar with that. Also, agree it can create unnecessary overhead, but I'm not against that. Maybe we can introduce them in a further iteration (to avoid having too many moving parts from the beginning). Anyway, let's discuss.
Regarding other tools, in my experience, they are too cumbersome for an open source. In particular, I don't see Jira as a community-friendly tool :sweat_smile: so I'd avoid that.
Thank you for that! I love the proposal and the idea of GitHub projects to keep track of what we are doing! Agree with @incertum, we should avoid adding too much overhead to our daily work, for this reason probably at the beginning I would use just one tool to manage all and then maybe we can put in place something else :thinking:
Hey maintainers,
the meeting is confirmed for Thu 27th April 9am PT / 6pm CEST. I'll send you a calendar invite shortly.
Hey folks,
Here are the meeting notes :point_right: https://github.com/falcosecurity/community/pull/190
TL;DR We agreed on the proposal and intended to create a WG to implement it. We defined a few action items to kick off the new process that we aim to introduce starting from the Falco 0.36 development cycle (i.e., from June)
:partying_face:
Update:
If you need some help I'm on board with the WG! Just one suggestion, I would keep it as flexible as possible maybe a Slack channel or something like that, I would avoid fixed meetings or bureaucratic procedures if not needed :)
+1
I'll be happy to help here. Also agree with Andrea's comment, a simple channel would be a good place to start.
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