Define new project management workflow

project-management.md

@@ -0,0 +1,37 @@
+# Project Management
+
+The OpenTelemetry community has limited bandwidth for managing changes which expand the scope of OpenTelemetry, or impact many SIGs within OpenTelemetry. There are three common scenarios which have this kind of impact.
+* Non-trivial changes to the OpenTelemetry specification.
+* A new SIG being formed.
+* An existing SIG taking on new work which will affect the OpenTelemetry project as a whole, and will need review from the broader community.
+
+Any changes which fall into one of the above categories must first create a project proposal and gain approval from the GC and TC before work begins.
+
+## Project Proposal
+
+At minimum, projects require the following resources to be successful:
+
+* A clearly defined set of goals and deliverables.
+* Deadlines for when the deliverables will be ready for review by the broader community.
+* Two TC/GC members, or community members delegated by the them, to sponsor the project.
+* A group of designers and subject matter experts need to dedicate a significant amount of their work time to the project. These participants are needed to design the spec, write a set of OTEPs, and create multiple prototypes. This group needs to meet with each other (and with their sponsors) on a regular basis to develop a successful set of proposals.
+
+To propose a project, please create a **project document** using the [project template](project-template.md) as a guide. This document will be used as the initial proposal for the project.
+
+You can then submit the proposal by placing the project document in the [projects](projects/) folder and making a pull request against the community repo. A project is officially approved by merging the pull request.
+
+As the project progresses, the project document should be kept up to date, and the community [README](README.md) should be updated to include any new project meeting information.
+
+Groups are encouraged to define deadlines for any work which will require public review. We have found that having a goal leads to an increased cadence in project work, and helps resolve debate. Deadlines also help with getting a more coherent public review, as they allow the review community to plan on making themselves available. If deadline prove to be unrealistic, they can be always be updated.
+
+## Project Lifecycle
+
+All projects progess through a lifecycle. Projects are tracked on the [Project Board](https://github.com/orgs/open-telemetry/projects/29), which the community can use to get a high-level view of the OpenTelemetry roadmap.
+
+The project lifecycle is as follows:
+
+* A **Project Proposal** pull request is created, as described above.
+* If a project is approved, the pull request is merged. The project is then added to the list of **Potential Projects**. This list is roughly ordered based on priority.
+* Potential projects are moved to the list of **Scheduled Projects** once they have a planned start date. Having a planned start date lets potential contributors know when they need to make themselves available, and get prepared to begin their work. Subject matter experts and participants who plan to do a lot of work – such as building prototypes – benefit greatly from having a start date, as they can plan for their participantion with their employers and coworkers.
+* Once a project is begun, it is moved to the list of **Current Projects**. Projects are only started when the necessary resources are available to move them quickly to completion. This means that the necessary subject matter experts have been identified, and at least two TC members are committed to review and guide the project through the specification process.
+* Once work is complete, and the working group is no longer meeting, the project document is moved to the [completed projects](projects/completed-projects/) folder.

project-template.md

@@ -0,0 +1,47 @@
+# <<PROJECT NAME>>
+
+## Description
+
+Describe the goals, objectives, and requirements for the project. This include the motivations for starting the project now, as opposed to later.
+
+## Deliverables
+
+A description of what this project is planning to deliver, or is in the process of delivering. This includes all OTEPs and their associated prototypes.
+
+In general, OTEPs are not accepted unless they come with working prototypes available to review in at least two languages. Please discuss these requirements with a TC member before submitting an OTEP.
+
+## Staffing / Help Wanted
+
+Who is currently planning to work on the project? If a project requires specialized domain expertise, please list it here. If a project is missing a critical mass of people in order to begin work, please clarify.
+
+### Required staffing
+
+Projects cannot be started until the following participants have been identified:
+* Every project needs a project lead, who is willing to bottom line the project and address any issues which are not handled by other project members.
+* At least two sponsoring TC members. TC sponsors are dedicated to attending meetings, reviewing proposals, and in general being aware of the state of the project and its technical details. TC sponsors guide the project through the spec process, keep the tracking issue up to date, and help to ensure that relevant community members provide input at the appropriate times.
+* Engineers willing to write prototypes in at least two languages (if relevant to project). Languages should be fairly different from each other (for example: Java and Python).
+* Maintainers or approvers from those languages committed to reviewing the prototypes.
+
+## Meeting Times
+
+Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
+
+## Timeline
+
+What is the expected timeline the project will aim to adhere to, and what resources and deliverables will be needed for each portion of the timeline? If the project has not been started, please describe this timeline in relative terms (one month in, two weeks later, etc). If a project has started, please include actual dates.
+
+## Labels
+
+The tracking issue should be properly labeled to indicate what parts of the specification it is focused on.
+
+## Linked Issues and PRs
+
+All PRs, Issues, and OTEPs related to the project should link back to the tracking issue, so that they can be easily found. 
+
+## Project Board
+
+Once approved by TC, a project should be managed using a GitHub project board. This project board should be pre-populated with issues that cover all known deliverables, organized by timeline milestones.
+
+A [Technical Committee](https://github.com/open-telemetry/community/blob/main/community-members.md#technical-committee) (TC) member associated with the project can create the board, along with a new project-specific GitHub label to automatically associate issues and PRs with the project. The project lead and all other relevant project members should have edit access to the board.
+
+Once created, please link to the project board here.

projects/README.md

@@ -0,0 +1 @@
+This folder contains all OpenTelemetry projects which have been approved by the GC. Please see the [project board](https://github.com/orgs/open-telemetry/projects/29) for an overview of the state of every project.

projects/client-instrumentation.md

@@ -0,0 +1,56 @@
+# Client Instrumentation
+
+## Description
+
+We believe that in order for OpenTelemetry to be adopted across the board, it needs to have a good support for client applications. Client instrumentation has some unique challenges that are currently not well supported.
+
+Our initial goals include
+
+* define which signal(s) are used for different types of client telemetry
+* define semantic conventions for different types of client events
+* define semantic conventions for client-specific resources
+* define how sessions are handled in SDKs and represented across the wire
+
+Beyond these, we expect that this will be a long-term ongoing project, which might include development of client-optimized SDKs. Also, given that there are many types of client applications/environments, this group may branch into multiple groups over time.
+
+## Project Board
+
+https://github.com/orgs/open-telemetry/projects/19/views/1
+
+## Deliverables
+
+* Semantic conventions for (most common) client events
+  * [draft PR for two browser events](https://github.com/martinkuba/opentelemetry-specification/pull/1)
+* Semantic conventions for (most common) client resources
+  * [Ephemeral Resources OTEP](https://github.com/open-telemetry/oteps/pull/208)
+* Logs/Events API + SDK in the Javascript SDK
+  * [specification PR](https://github.com/open-telemetry/opentelemetry-specification/pull/2676)
+  * [API draft implementation in JS](https://github.com/open-telemetry/opentelemetry-js/pull/3117)
+* Logs/Events API + SDK for Android
+* Logs/Events API + SDK for Swift
+* Implementation of sessions in the Javascript SDK
+* Research + proposal for how browser SDK should be optimized
+  * [sandbox repository for experimentation](https://github.com/open-telemetry/opentelemetry-sandbox-web-js)
+
+## Staffing / Help Wanted
+
+Expertise required: browser instrumentation, mobile instrumentation
+
+The group currently has several regular contributors who have expertise in browser instrumentation. Most of the focus so far has been on browser and shared concerns across all types of client applications. We need more participation from mobile in order to move mobile instrumentation forward.
+
+### Required staffing
+
+Project lead(s): @martinkuba, @scheler, @MSNev
+
+TC sponsoring members:
+Josh Sureth, Jack Berg
+
+## Meeting Times
+
+SIG meeting times: Mondays 12:30am PT
+Secondary meeting times: Tuesdays 9am PT
+Timeline
+
+##  Timeline
+6 - 12 months
+

projects/completed-projects/README.md

@@ -0,0 +1 @@
+This folder contains projects which have been completed, and are no longer meeting as a group.

projects/config.md

@@ -0,0 +1,55 @@
+# OpenTelemetry Configuration
+
+## Description
+
+OpenTelemetry specifies code that can operate in a variety of ways based on the end-user’s desired mode of operation. This requires a configuration interface be provided to the user so they are able to communicate this information. Currently, OpenTelemetry specifies this interface in the form of environment variables. This environment variable interface is limited in the structure of information it can communicate and the primitives it can support.
+
+The configuration project intends to produce the specification around the data model for language-agnostic configuration that provides additional flexibility for the end users.
+
+## Project Board
+
+https://github.com/orgs/open-telemetry/projects/38
+
+## Deliverables
+
+1. An OTEP
+2. Prototypes in Java, Python, Go, Erlang
+3. The specification of the configuration data model
+4. A repository containing the schema and schema validation tooling
+
+## Staffing / Help Wanted
+
+End users of OpenTelemetry to help validate the usage and configuration scenarios would be great to have participate in the discussions.
+
+## Required staffing
+
+Project lead
+
+* @MrAlias
+* @jack-berg
+
+Sponsoring TC members
+
+* @carlosalberto
+
+Engineers contributing to the working group
+
+* @MrAlias
+* @jack-berg
+* @tsloughter
+* @MikeGoldsmith
+* @codeboten
+
+Maintainers and approvers
+
+* @srikanthccv (python)
+* @CodeBlanch (.net)
+* @lalitb (c++)
+
+## Meeting Times
+
+Every 2 weeks, on Fridays at 10:30AM PT
+
+## Timeline
+
+3-6 months

projects/faas.md

@@ -0,0 +1,81 @@
+# FAAS SIG
+
+## Description
+
+The initial goal of this project is to put Lambda monitoring into a consistently good state. Across vendors, customers consistently struggle to instrument their Lambdas and identify the best practices way to monitor a Lambda. Lambda layer behavior differs by language, context propagation is frequently broken, and cold starts are a known issue.
+
+This SIG will also look beyond Lambdas and to more broadly Functions as a Service.
+
+We want to ensure:
+
+* The FAAS spec has been reviewed, assessed to apply generically, and stabilized
+* Consistent lambda layer behavior by language and uniform conformance to the spec
+* There is clear community guidance on how to monitor Lambdas
+* End to end context propagation using community protocols / propagation across typical Lambda architectures (e.g async)
+* Cold start data capture and submission
+* The new TelemetryAPI is properly integrated and utilized by OpenTelemetry
+
+**This SIG will also serve as a working group for all FAAS topics going forward.**
+
+## Deliverables
+
+* Stabilized FAAS semantic conventions
+* Updated Lambda Layer extensions that follow consistent trace propagation and have consistent behavior across languages.
+* Cold start processor for the collector
+* The first 2 language implementations will be Node.JS and Python.
+
+## Staffing / Help Wanted
+
+The following vendors are interested in improving this area.:
+
+* Lightstep
+* AWS
+* Splunk (@tsloughter)
+* Cisco (@arbiv)
+* Honeycomb (@cartermp)
+
+While Lambdas are the focus of this effort we need other Functions As A Service (FAAS) experts to ensure we're building conventions that make sense for the stateless function space in general. GCP or Azure participation would be welcome.
+
+## Required staffing
+
+Project Lead:
+@Aneurysm9
+
+Sponsoring TC Members:
+* @carlosalberto
+* TBA
+
+Implementation Engineers:
+* @tylerbenson
+* @codeboten
+* Cisco contributors (@arbiv)
+* Honeycomb contributors (@cartermp)
+* @tsloughter
+* @xoscar
+
+Implementation Maintainers or Approvers:
+* JavaScript - @mwear
+* Python - @ocelotl
+
+Lambda SME(s):
+@Aneurysm9 to add
+
+## Meeting Times
+
+To deliver the improvements promptly we propose meeting at least 2 days a week for the 6 week planning cycle as specified in the new Semantic Conventions Process Doc
+
+Meeting Times:
+
+PST Option: Tuesday @ 12 pm PST
+CET Option: Wednesday @ 7 am PST
+
+## Timeline
+
+1. New working group will be kicked off in January
+2. The WG has 6 weeks to propose improvements to the specification and solutions - Beginning of March
+3. OTeps and the first implementation in JavaScript will be reviewed by the community - All of March
+4. Implementation - we want to start with JavaScript and Python as our first target implementation languages - Beginning of April
+
+## Repo
+
+https://github.com/open-telemetry/opentelemetry-lambda

projects/http.md

@@ -0,0 +1,47 @@
+## Description
+
+Get the HTTP semantic conventions across the finish line to stability, and afterwards update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions.
+
+## Project Board
+
+https://github.com/orgs/open-telemetry/projects/41
+
+## Deliverables
+
+* Mark the HTTP semantic conventions as stable.
+* Update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions.
+
+## Staffing / Help Wanted
+
+The goal is to follow @tedsuo's proposed [Semantic Convention Process](https://docs.google.com/document/d/1ghvajKaipiNZso3fDtyNxU7x1zx0_Eyd02OGpMGEpLE/edit#heading=h.xc2ft2cddhny).
+
+* __Stage 1__: Working Group Preparation
+* __Stage 2__: Specification
+* __Stage 3__: Implementation
+
+### Required staffing for Stage 1 and 2
+
+* @trask project lead
+* @denisivan0v domain expert
+* @lmolkova domain expert
+* @mateuszrzeszutek prototyping in Java
+* @reyang technical committee sponsor
+* @jsuereth technical committee sponsor
+* Need: more domain experts
+* Need: engineers willing to write prototypes in at least one more language other than Java. Language should be fairly different from Java (for example: Python).
+* Need: maintainers or approvers from those languages committed to reviewing the prototypes.
+
+### Required staffing for Stage 3
+
+* @trask project lead
+* @mateuszrzeszutek updating Java instrumentation
+* Need: engineers across all languages willing to update existing HTTP instrumentation across all OpenTelemetry repositories to conform with the stable conventions.
+* Need: maintainers or approvers across all languages committed to reviewing the updates.
+
+## Meeting Times
+
+Once a project is started, the working group should meet regularly for discussion. These meeting times should be posted on the OpenTelemetry public calendar.
+
+## Timeline
+
+All work has been completed.