Monthly meeting agenda (Feb 2022)

[jptosso]

Meeting date: Wednesday 23rd, 12hrs UTC

Topics

1. Project status overview
2. Contribution requirements: Licenses, dependencies, testing, quality gates, approval flow, etc
3. Criteria for a new feature and approval flows
4. Where to store plugins and which plugins should be merged
5. Gifts on PRs, is it ok? what is the policy?
6. Coraza vulnerability handling
7. Project core values
8. Rules for the future meetings
9. v2 final version release requirements
10. Where to publicly store all coraza research? Public confluence or GH wiki
11. Side projects status and future (website, sandbox, docker, caddy, traefik, gin, and coraza-server)
12. If there is time, we might discuss the google summer of code event
13. How to deal with bugs from pre-releases and v1
14. README structure
15. Response body processor

To join, request a slack invite here https://owasp.org/slack/invite and join the coraza channel.

Other considerations

• Feel free to request additional topics or propose a new schedule
• The duration of the meeting is expected to be 60 minutes.

[fzipi]

Personally I'll prefer Wed 13Hrs UTC. 60 minutes? Maybe because is the first one :)

Topics look good. For 12) I think it is better to throw stuff at a document first.

[fzipi]

Meeting Notes

1. Official new name is OWASP Coraza Web Application Firewal. Juan Pablo presented the team of leaders and contributors.
2. With regard to the contribution requirements:

• add Apache 2 compatible licenses for those who implement additional features and might use third party go modules (e.g. MIT, BSD, and Apache are). Check if we can use go-licenses in a CI/CD check.
• quality gates: new code should keep the 80% quality gate on coverage. If maintainers/contributors with merge powers deem the code to be reasonable, they might force merge.
• if we introduce a new dependency, we rely on the quality standards from awesome-go.com
• No CGo is permitted in the core.

3. Approval flows: each PR should have 2 approvers. When we grow, we should use also the CODE_OWNERS feature. New features: Core features: should go by the approval format. Non Core Features: should start as plugins/modules, once tested they can go to the core.
4. Plugins: skipped to next meeting, while we get more documentation.
5. Gifts: let's ask around other projects and formally to OWASP and we can deal with this next meeting.
6. Vulnerability handling: will create an email address like [email protected] with secure GPG and forward it to core contributors and co-leaders
7. Core values: will be discussed next meeting

Remaining topics will be discussed in next meeetings.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[jptosso]

All topics covered in the March meeting