# Developer Experience Working Group (draft)

Developer Experience Working Group is a team trying to make the Go programming language, libraries and tools more pleasant to use. The team primarily works on the Go project, even though its responsibilities and activities may involve contributing to the ecosystem-wide impactful projects. The group is aimed to cover a highly specialized field of expertise that is not always well-covered by the core team.

## Goals

* Making Go a preferred language in industry and education.
* Helping the language graduate to a mainstream language by enabling the early majority developers.
* Helping Go to succeed in organizations with opinionated infrastructure and tooling.

## Projects
Ongoing projects, feel free to reach out to the project lead if you want to collaborate:

- Improvements to the Go installation experience (Chris Broadfoot <cbro@golang.org>)
- Guides on tooling and developer environments (editors and IDEs) (Jaana B. Dogan <jbd@golang.org>)
- Running user studies to systematically analyze and measure friction points (Chris Broadfoot <cbro@golang.org>, Katrina Owen <katrina.owen@gmail.com>, Steve Francia <sfrancia@google.com>)
- Improvements to the Go Tour and Go Playground (Chris Broadfoot <cbro@golang.org>, Steve Francia <sfrancia@google.com>)
- Better guidelines to help new users and visual aids for golang.org (Jaana B. Dogan <jbd@golang.org>)

## Channels
* Mailing list: [golang-devexp](https://groups.google.com/forum/#!forum/golang-devexp)
* Gophers Slack channel if you need synchronous help: [#devexp](https://gophers.slack.com/archives/devexp) ([invitation](https://invite.slack.golangbridge.org/))

## Responsibilities and Activities
* Identify the barriers for newcomers and remove them to make Go succeed as a mainstream programming language.
Revamp the existing docs and tools.
* Systematically collect feedback from the Go users to improve friction points in standard library, tools, docs, language and the ecosystem. The group may also run UX studies.
* Help identifying the critical missing libraries/tools from the ecosystem.
* At each release cycle, review new standard library APIs to give feedback about usability, self-explanation and documentation.
* Participate in user-facing Go proposals to give usability feedback.
* Encourage readable and idiomatic APIs. Be the voice of best practices in API design.
* Contribute with technical writing on the Go blog to fill the gaps in communication.

## Roles

The group has a variety of roles with specific responsibilities. Although it is not a hard requirement, all contributors are expected to have background and technical expertise in one or more of these fields: API design, developer tooling, readability, programming language design and education, and technical writing.

### Leads
We are expecting this role to require 15 hours of commitment each week.
* All responsibilities of the members
* Ensuring contributors are sufficiently productive and not blocked
* Reaching consensus if there is no obvious answer
* Organizing meetings and handling paperwork

### Members
We are expecting this role to require 10 hours of commitment each week.
* All responsibilities of the participants
* Doing the first CL and proposal reviews
* Setting high-level goals and establishing long-term milestones
* Mentor community about best practices

### Participants
Participants don't have to commit to any long-term plans, they work as much as they want on gradual improvements and contribute to the discussion.
* Creating CLs and proposals
* Participating in discussions