Draft list of objectives to increase community transparency and engagement

• Communication regarding the development of TF features and bugs is done in TF JIRA  
  • Why it was added? There were concerns that the development of features by partners like Juniper is not transparent and visible to the community 
• Test documentation is stored in the TF repository and can be freely accessed
  • Why it was added? There were moments where some parts of the documentation of features (like test scenarios) were kept outside Tungsten Fabric domain
• Build procedure is written down and it’s stored in docs.tungsten.io 
  • Why it was added? Currently, that knowledge exists on confluence pages and inside the head of the team that runs the CI. To increase the bus factor we must document everything that will allow us to create a new official build. 
• Script for building TF are stored in tf-jenkins repository 
  • Why it was added? We must have certainty that the source code in the repository allows us to set up CI from the scratch
• CI is managed by clearly nominated LF administrators or community members with all needed privileges
  • Why it was added? We as a community need to know who is responsible and accountable for the CI and who would be our first point of contact in case of any troubles
• CI infrastructure is documented
  • Why it was added? CI infrastructure is in Vexxhost but we lack a transparent description of what machines do we have and what purpose do they serve. Without that description, it is hard for anyone to set up their own Tungsten Fabric CI.
• Documentation of where release artifacts are stored (docker hub etc.) is in docs.tungsten.io and what naming convention they follow
  • Why it was added? Almost every release we have a discussion about who can add builds, where are they kept and what is the naming convention. To minimize the time we spend on those unnecessary discussions lets document that.
• LF administrators have access to all places where release artifacts are stored (docker hub etc.)
  • Why it was added? Some of the credentials to systems used by the TF project (like CI) are known only to community members. As a backup, we need to share them with the LFN DevOps team.
• Release artifacts are published by LF administrators, or people designated by TSC, after TSC approval
  • Why it was added? In case community members that run the CI will be unable to full fill their tasks, we need to have ability to do that using the help LFN DevOps team.
• All code added to TF is exposed in TF either through WebUI, API, or CLI. This means there is no code that is consumed only by proprietary additions
  • Why it was added? There was a situation where the feature added to a codebase was consumed only by commercial extension created by the partner. That creates a problem where the community cannot review nor test such code. That is why every single code should be exposed either via WebUI or CLI and it should be documented in TF docs.
• PTL responsible for the development of new features delivers Release Notes for those features at the moment  required by a milestone description
  • Why it was added? We had a number of situations where the release was postponed because we were waiting for the release notes for a particular feature. 
• PTL responsible for the development of new features delivers documentation for those features at the moment  required by a milestone description
  • Why it was added? We had a number of situations where the release was postponed because we were waiting for the documentation of a particular feature. 
• PTL complies with TF release procedure (keeping EPIC up-to-date, TSC approvals, planning, delivery of the code, documentation, etc.)
  • Why it was added? As a part of transparency, a PTL needs to ensure that anyone developing a feature in the domain for which PTL is responsible, complies with TF release procedure 
• There is a person responsible for de-contralization of the source code
• There is a roadmap of code de-contralization
  • Why it was added? There were concerns about Contrail naming that exists in the source code (names of API endpoints, names of CLI procedures, etc.). The current understanding of the legal part is that Juniper is aware that it dilutes the Contrail naming but otherwise there are no other problems with that. From the community perspective, it is somehow uncomfortable to use the naming of another project in our codebase and documentation. If it bothers you please assign a high priority to this point
• Code added to TF repo doesn’t use naming other than Tungsten Fabric / TF
  • Why it was added? There were concerns about Contrail naming that exists in the source code (names of API endpoints, names of CLI procedures, etc.). The current understanding of the legal part is that Juniper is aware that it dilutes the Contrail naming but otherwise there are no other problems with that. From the community perspective, it is somehow uncomfortable to use the naming of another project in our codebase and documentation. If it bothers you please assign a high priority to this point
• All documents/blueprints/tests added to TF repo doesn’t use naming other than Tungsten Fabric / TF
  • Why it was added? There were concerns about Contrail naming that exists in the source code (names of API endpoints, names of CLI procedures, etc.). The current understanding of the legal part is that Juniper is aware that it dilutes the Contrail naming but otherwise there are no other problems with that. From the community perspective, it is somehow uncomfortable to use the naming of another project in our codebase and documentation. If it bothers you please assign a high priority to this point
• All code migrated or added to TF has at least unit tests coverage and tests cannot be omitted from the development process
  • Why it was added? Both Tungsten Fabric and Juniper make different builds from the same code. That means that even though Juniper provides manual testing it doesn't give us 100% certainty that TF build will work flawlessly. That is why we need to incorporate as many automated tests as possible. And that is why we need to have unit tests.
• Marketing channels (twitter, linkedin etc.) are managed by a person selected by the TSC or LFN representative
  • Why it was added? Marketing efforts should be discussed and planned with the TSC. Currently, TSC doesn't have control over that process.
• Transparent project roadmap for the next release
  • Why it was added? The community must know what is being developed and by who.

Communication regarding the development of TF features and bugs is done in TF JIRA  
Test documentation is stored in the TF repository and can be freely accessed 
Build procedure is written down and it’s stored in docs.tungsten.io 
Script for building TF are stored in tf-jenkins repository 
CI is managed by clearly nominated LF administrators with all needed privileges
CI infrastructure is documented
Documentation of where release artifacts are stored (docker hub etc.) is in docs.tungsten.io and what naming convention they follow
LF administrators have access to all places where release artifacts are stored (docker hub etc.)
Release artifacts are published by LF administrators, or people designated by TSC, after TSC approval
All code added to TF is exposed in TF either through WebUI, API, or CLI. This means there is no code that is consumed only by proprietary additions
PTL responsible for the development of new features delivers Release Notes for those features at the moment required by a milestone description
PTL responsible for the development of new features delivers documentation for those features at the moment required by a milestone description
PTL complies with TF release procedure (keeping EPIC up-to-date, TSC approvals, planning, delivery of the code, documentation, etc.)
There is a person responsible for de-contralization of the source code
There is a roadmap of code de-contralization
Code added to TF repo doesn’t use naming other than Tungsten Fabric / TF
All documents/blueprints/tests added to TF repo doesn’t use naming other than Tungsten Fabric / TF
All code migrated or added to TF has at least unit tests coverage and tests cannot be omitted from the development process
Marketing channels (twitter, linkedin etc.) are managed by a person selected by the TSC or LFN representative
Transparent project roadmap for the next release