-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #114 from alphagov/kellylee-gds-patch-4
Create community objectives page in the playbook
- Loading branch information
Showing
2 changed files
with
81 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,80 @@ | ||
--- | ||
title: Community objectives | ||
weight: 5 | ||
--- | ||
# Community objectives | ||
|
||
This page details our community objectives in 2025. We will review progress against these objectives every quarter, and iterate targets if needed. | ||
|
||
## Maintain and improve reach to our community | ||
|
||
### What we want to do | ||
|
||
- reach core community members (ie people building GOV.UK services) frequently | ||
- reach peripheral community members (eg private sector, international design systems, local government) at least once a year | ||
- be seen as leaders of design system so we draw new users into our community, and adds legitimacy and trust to our product | ||
- attract new members to our community and ensuring they feel valued | ||
|
||
### Key results | ||
|
||
- 25% of the community attend at least one activity each quarter | ||
- 2% increase in new members of the community (via mailing list subscriptions) | ||
- TBD increase in contributions by community members | ||
- TBD increase in repeat attendees | ||
- TBD satisfactory balance of core community members vs peripheral members attending our community activities | ||
|
||
## Diversity and inclusion | ||
|
||
### What we want to do | ||
|
||
We want to have a diverse and inclusive community which represents all our users. | ||
|
||
This means recruiting a diverse group of speakers at our events, ensuring there is gender parity, and increased contribution from underrepresented ethnic groups. We also want to see a range of disciplines and experience levels, from a wide variety of departments and sectors. | ||
|
||
We also want the format of community events to be inclusive. This means: | ||
|
||
- we host a satisfactory mix of in-person, hybrid and online events | ||
- we provide accessible tools and technologies | ||
- catering choices are inclusive to those with dietary requirements | ||
- social events are not limited to bars or pubs | ||
- recordings of community events are full captioned and available on the website for users to watch | ||
- we host events on different days of the week, and at different time | ||
|
||
### Key results | ||
|
||
- TBD increase in contributions from underrepresented groups | ||
- at least 1 first time contributor each quarter | ||
|
||
## Team collaboration | ||
|
||
### What we want to do | ||
|
||
We want the team to engage with the community so that they get the insights, evidence and ideas to make decisions about their work and build a design system which meets our user’s needs. | ||
|
||
We expect the community designer and associated delivery manager to spend 50% of their time supporting the team to engage with the community. For example, helping to plan workshops or design crits, helping to recruit steering groups, and preparing presentations at community events. | ||
|
||
We want to coach and upskills the team over time so they become more skilled and confident in doing community-facing work independently. | ||
|
||
### Key results | ||
|
||
- all team members have participated in a community event each quarter in some capacity | ||
- at least 50% of the team have shared something at a community or GDS event each quarter | ||
- we run at least one team session per cycle to promote external communication | ||
- each new component and pattern, major version of GOV.UK Frontend or major change to the website architecture must have a community kick off or announcement, at least one crit or co-design session, and a release celebration | ||
- the team playbook will include guides in how to run and support community activities | ||
|
||
## Improve the onboarding process | ||
|
||
### What we want to do | ||
|
||
We want to make it easier for potential community members to find out how to join our community and discover how to take part in events. | ||
|
||
We want to make people feel welcome, whether they work in government or not; whether they are from the UK or not; and whether they are design system user or not. We want people to know that all contribution is welcome. | ||
|
||
We want all information on events, steering groups and contributions processes to be available and findable. | ||
|
||
### Key results | ||
|
||
- the website is up to date at the time of ticket releases | ||
- the Community section on the website contains current information | ||
- 2% increase in new community members each quarter |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters