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.


Click for anchor link test Export to CSV Clear All Votes

Click for anchor link Summary

Question Total Votes Average Score
Communication regarding the development of TF features and bugs is done in TF JIRA   14
3.71
Test documentation is stored in the TF repository and can be freely accessed  14
3.14
Build procedure is written down and it’s stored in docs.tungsten.io  14
3.29
Script for building TF are stored in tf 13
3.92
CI is managed by clearly nominated LF administrators with all needed privileges 13
2.38
CI infrastructure is documented 14
2.36
Documentation of where release artifacts are stored (docker hub etc.) is in docs.tungsten.io and what naming convention they follow 14
3.79
LF administrators have access to all places where release artifacts are stored (docker hub etc.) 11
2.91
Release artifacts are published by LF administrators, or people designated by TSC, after TSC approval 10
3.60
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 14
2.71
PTL responsible for the development of new features delivers Release Notes for those features at the moment required by a milestone description 11
3.55
PTL responsible for the development of new features delivers documentation for those features at the moment required by a milestone description 11
3.55
PTL complies with TF release procedure (keeping EPIC up 10
3.40
There is a person responsible for de 10
2.70
There is a roadmap of code de 11
2.45
Code added to TF repo doesn’t use naming other than Tungsten Fabric / TF 12
2.42
All documents/blueprints/tests added to TF repo doesn’t use naming other than Tungsten Fabric / TF 12
2.83
All code migrated or added to TF has at least unit tests coverage and tests cannot be omitted from the development process 11
3.36
Marketing channels (twitter, linkedin etc.) are managed by a person selected by the TSC or LFN representative 9
2.89
Transparent project roadmap for the next release 12
3.67

Click for anchor link Communication regarding the development of TF features and bugs is done in TF JIRA  

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
10 Votes , 71%
3-Highly needed
4 Votes , 28%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%

Click for anchor link Test documentation is stored in the TF repository and can be freely accessed 

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
2 Votes , 14%
3-Highly needed
12 Votes , 85%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%

Click for anchor link Build procedure is written down and it’s stored in docs.tungsten.io 

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
7 Votes , 50%
3-Highly needed
4 Votes , 28%
2-Needed
3 Votes , 21%
1-less needed
0 Votes , 0%

Click for anchor link Script for building TF are stored in tf

jenkins repository 
Choices Your Vote Current Result: (13 Total Votes)
4-Critical
12 Votes , 92%
3-Highly needed
1 Vote , 7%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%

Click for anchor link CI is managed by clearly nominated LF administrators with all needed privileges

Choices Your Vote Current Result: (13 Total Votes)
4-Critical
0 Votes , 0%
3-Highly needed
5 Votes , 38%
2-Needed
8 Votes , 61%
1-less needed
0 Votes , 0%

Click for anchor link CI infrastructure is documented

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
0 Votes , 0%
3-Highly needed
6 Votes , 42%
2-Needed
7 Votes , 50%
1-less needed
1 Vote , 7%

Click for anchor link Documentation of where release artifacts are stored (docker hub etc.) is in docs.tungsten.io and what naming convention they follow

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
12 Votes , 85%
3-Highly needed
1 Vote , 7%
2-Needed
1 Vote , 7%
1-less needed
0 Votes , 0%

Click for anchor link LF administrators have access to all places where release artifacts are stored (docker hub etc.)

Choices Your Vote Current Result: (11 Total Votes)
4-Critical
3 Votes , 27%
3-Highly needed
4 Votes , 36%
2-Needed
4 Votes , 36%
1-less needed
0 Votes , 0%

Click for anchor link Release artifacts are published by LF administrators, or people designated by TSC, after TSC approval

Choices Your Vote Current Result: (10 Total Votes)
4-Critical
6 Votes , 60%
3-Highly needed
4 Votes , 40%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%

Click for anchor link 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

Choices Your Vote Current Result: (14 Total Votes)
4-Critical
0 Votes , 0%
3-Highly needed
11 Votes , 78%
2-Needed
2 Votes , 14%
1-less needed
1 Vote , 7%

Click for anchor link PTL responsible for the development of new features delivers Release Notes for those features at the moment required by a milestone description

Choices Your Vote Current Result: (11 Total Votes)
4-Critical
7 Votes , 63%
3-Highly needed
3 Votes , 27%
2-Needed
1 Vote , 9%
1-less needed
0 Votes , 0%

Click for anchor link PTL responsible for the development of new features delivers documentation for those features at the moment required by a milestone description

Choices Your Vote Current Result: (11 Total Votes)
4-Critical
7 Votes , 63%
3-Highly needed
3 Votes , 27%
2-Needed
1 Vote , 9%
1-less needed
0 Votes , 0%

Click for anchor link PTL complies with TF release procedure (keeping EPIC up

to
Choices Your Vote Current Result: (10 Total Votes)
4-Critical
4 Votes , 40%
3-Highly needed
6 Votes , 60%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%

Click for anchor link There is a person responsible for de

contralization of the source code
Choices Your Vote Current Result: (10 Total Votes)
4-Critical
0 Votes , 0%
3-Highly needed
8 Votes , 80%
2-Needed
1 Vote , 10%
1-less needed
1 Vote , 10%

Click for anchor link There is a roadmap of code de

contralization
Choices Your Vote Current Result: (11 Total Votes)
4-Critical
0 Votes , 0%
3-Highly needed
6 Votes , 54%
2-Needed
4 Votes , 36%
1-less needed
1 Vote , 9%

Click for anchor link Code added to TF repo doesn’t use naming other than Tungsten Fabric / TF

Choices Your Vote Current Result: (12 Total Votes)
4-Critical
2 Votes , 16%
3-Highly needed
3 Votes , 25%
2-Needed
5 Votes , 41%
1-less needed
2 Votes , 16%

Click for anchor link All documents/blueprints/tests added to TF repo doesn’t use naming other than Tungsten Fabric / TF

Choices Your Vote Current Result: (12 Total Votes)
4-Critical
5 Votes , 41%
3-Highly needed
2 Votes , 16%
2-Needed
3 Votes , 25%
1-less needed
2 Votes , 16%

Click for anchor link All code migrated or added to TF has at least unit tests coverage and tests cannot be omitted from the development process

Choices Your Vote Current Result: (11 Total Votes)
4-Critical
5 Votes , 45%
3-Highly needed
5 Votes , 45%
2-Needed
1 Vote , 9%
1-less needed
0 Votes , 0%

Click for anchor link Marketing channels (twitter, linkedin etc.) are managed by a person selected by the TSC or LFN representative

Choices Your Vote Current Result: (9 Total Votes)
4-Critical
2 Votes , 22%
3-Highly needed
5 Votes , 55%
2-Needed
1 Vote , 11%
1-less needed
1 Vote , 11%

Click for anchor link Transparent project roadmap for the next release

Choices Your Vote Current Result: (12 Total Votes)
4-Critical
8 Votes , 66%
3-Highly needed
4 Votes , 33%
2-Needed
0 Votes , 0%
1-less needed
0 Votes , 0%


  • No labels

1 Comment

  1. Ian Rae

    Nick Davey  suggests adding project wide "roadmap" proposal and a plan for the community.