What?

The Technical Advisory Office will help projects under the Linux Foundation Networking solve problems they are dealing with using expertise of community members.

Why?

Projects under the LFN seem to be dealing with addressing similar challenges, yet there is little information sharing between the various projects. The issue is not unwillingness to share, but rather lack of information about the right counterparts in other projects who may posses the right knowledge.

The type of issues that tend be common to multiple projects are around:

  • Projects infrastructure - build and test environments, tools, etc. 
  • Stability, Security, Scalability, Performance (S3P).
  • Data and Information modeling
  • ...

Making the right connections between individuals and teams who work on similar problems in different projects could let some projects benefit from the work done in others. It would hopefully avoid parallel efforts in different projects and create synergies between projects. Having to address the similar problems more than once should encourage teams to document their efforts for the benefit of future projects.


How?

The Technical Advisory Office will focus on addressing issues that were already tackled by project teams under the LFN. Certainly not all challenges already have a solution in the community. In other cases a solution from project A may not be applicable to project B due to the use of different platforms, programming languages, deployment environment, etc. However our experience in the LFN community indicates that at least on the surface, some of the challenges faced by projects bare a certain similarity.

The role of the TAO should be strictly "Advisory". The intent is not to force projects to use the same methods and technologies, or to dictate a certain architecture. As such, it is proposed that the TAO will be driven by requests from the projects, and will not attempt to solicit cooperation where it was not explicitly requested by one of the projects.

The TAO main role is to facilitate the collaboration between projects, not necessarily play an active role in it. The facilitation should cover the following aspects:

  • Identifying groups or individuals in LFN projects that addressed similar issues, or posses expertise in the domain in question.
  • Create the necessary platform for collaboration - Wiki pages, Conference calls, Mailing list tags, etc.
  • Drive the collaboration by making sure information is exchanged in a proper and timely manner, the right individuals are involved, communication is documented and decisions are being made.
  • Make sure the process is documented for the benefit of future projects, especially the problem statement and proposed solution(s).
  • Follow up on the implementation of the solution and if required re-initiate the collaboration. Repeat until a satisfactory solution has been reached.


Where?

  • How should projects request assistance?
    • Tag on existing LFN TAC mailing list [TAO]

or

  • How to find the right expertise?
    • Start with the TAC members
    • Build a list SMEs
    • Post a request for assistance in mailing list(s) (which?)
  • Where should we document the process and generated information?
    • LFN Wiki TAO main page
    • We may decide on other platforms in the future.

Who?

There was a comment made during the TAC review of this proposal (by Frank Brockners ) about why the process described here is not just a role of the entire TAC. While the comment makes sense, it would be beneficial to have a smaller group of people driving this, so that the responsibility is not spread too thin.

Members of the TSC who volunteer to take an active role in the TAO:

Q&A

  1. Q: What should we do if there is no expertise under the LFN? Should we avoid the issue? Find external expertise in other communities? Professional experts?

A: We should not limit ourselves to the LFN scope only. If there are experts in other communities who are capable and willing to help, we should reach out to them.

  1. Q: Should the TAO make proactive proposals for sharing solutions across projects? (E.g. if one project successfully dealt with security hardening, maybe the TOC should make sure other projects are aware?)

A: That depends on the responsiveness of the projects. If we don't get too many requests for help from the projects, we can offer topics for collaboration.

  1. How to solicit requests? What should we do if there are too many? prioritize? 

A: We will start by using a mailing list tag and a wiki page. We welcome the challenge of dealing with multiple requests and prioritizing.



  • No labels

1 Comment

  1. Jason Hunt

    Thanks for the proposal Ranny.  I am in favor of this, just so long as we position it correctly.  I would agree this not a formal subcommittee of the TAC, but rather a "service that the TAC provides to the LFN projects".  Behind the scenes, we would have TAC member volunteers (as outlined above) along with volunteers from the LFN projects.  I think it's best if we avoid the perception that we're creating new boards, committees, etc.

    My input on the open questions section:

    1. While we should look for expertise within the LFN, we shouldn't hesitate reach out to other communities or to our own professional network to find experts.  In fact, that might be a good way to recruit more people to LFN!
    2. I think proactive cross-project proposals would be a great output from the TAC, as it would be driven from actual project needs rather than the TAC guessing as to what might be useful.
    3. I like the idea of using a tag on the TAC mailing list to request assistance, and then moving the heart of the process to a wiki once the request has been accepted.  Having too many requests would be a great problem to have!