Define new project management workflow

project-management.md

@@ -0,0 +1,33 @@
+# Project Management
+
+Some specification changes are small enough in scope such that they can be resolved with a single PR or an OTEP written by a single person. However, this is rarely the case for large, meaningful changes. Most spec work ends up being organized into projects.
+
+At minimum, projects require the following resources to be successful:
+
+* 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 TC members) on a regular basis to develop a successful set of proposals.
+* A portion of the TC needs to be aware of and participate in the development of the project, to review the proposals and help guide the participants through the specification process.
+* Spec approvers and the broader community need to be aware of progress being made on the project, so they can be prepared to participate when proposals are ready for review.
+
+## Project Document
+
+Every project must have a high level **Project Document**, which describes the project. This document will be used as the initial proposal for the project. Once a project is approved, the document should be frequently edited and kept up to date as the project progresses. 
+
+## Project Proposal
+
+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.
+
+## 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 they 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 it's 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/client-instrumentation.md

@@ -0,0 +1,55 @@
+# 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:
+
+## Meeting Times
+
+SIG meeting times: Wednesdays 8am PT
+Secondary meeting times: Tuesdays 9am PT
+Timeline
+
+##  Timeline
+6 - 12 months
+

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