Antitrust policies

...

Trevor Bramwell to check how difficult is to move pr-s, issues, branches and projects from GitHub to GitLab?
Gitlab will import all Github Issues & PRs (comments and labels), code (all branches), wikis, and milestones. If a Github user has not logged into Gitlab and associated their Github ID, PR and issue comments will be associated with the importing user.
We will want to ensure CNTT contributors have logged into Gitlab with their Github ID before the import. I will confirm if this is retroactive (user logs in after import) or not.
Trevor Bramwell clarify the migration plan
The migration plan can be found here. Please direct any comments or questions to the mailing list or add the topic to this meeting.
Trevor Bramwell clarify how can we adopt the current user roles of the CNTT repo to GitLab
Gergely Csatari ensure that we can have a discussion with someone from LF Legal about the charter.
All: Read the current Anuket, the CNCF and the XGVela charters and decide next week on which one we should base the new Anuket charter
Gergely Csatari to ask for review-s to pr 2274 in the notes mail of this meeting
Pankaj.Goyal to propose an initial version of the charter under Anuket Charter and TSC Procedures revisions#Basedonotherprojectscharters
- Proposed documents
Walter.kozlowski to add himself to https://github.com/cntt-n/CNTT/blob/master/CODEOWNERS in a pr
Scott: New milestones and labels to should be added to GitHub after we have the name for the new release

Organisation topics

RM is not aligned to any other projects being external or internal
RA-s should specify by the M1 milestone which RM version they "implement" in the actual release
- It is possible to "implement" the same version of RM what is developed in the same release cycle or part of it
- In case of partial implementation the implemented and not implemented requirements must be traceable back to RM
RI-s should specify by the M1 milestone which RA version they implement in the actual release
- It is possible to select only particular features from the RA
- In case of partial implementation the implemented and not implemented requirements must be traceable back to RA
RC-s should specify by the M1 milestone which RA version they implement in the actual release
- It is possible to select only particular features from the RA
- In case of partial implementation the implemented and not implemented requirements must be traceable back to RA
Definition of version of open source components (even major ones, like OpenStack or Kubernetes) should happen during the release in the scope of RA projects in agreement with their dependent projects
Open issues
- We should decide if we would like to define absolute or relative versions of the open source components