Let’s create a better overview of WP Sustainability issues

[YellowlimeNL]

So many people show their enthusiasm to the WordPress Sustainablity Team, resulting in many ideas and suggestions for things we can work on. The current "Issues overview" looks overwhelming and not welcoming to newcomers. What can we do to make it more clear members of the team and newcomers?

[LittleBigThing]

Last week I created a label per main theme focus:

• social
• environmental
• economical

Adding these labels further could help contributors select issues to work on.

[gusaus]

The current "Issues overview" looks overwhelming and not welcoming to newcomers.

Couple ideas/suggestions from my experience participating and/or observing other teams (many/all of these have been mentioned in related admin issues or related discussions):

• Have three reps claim a particular focus area (see Determine team roles, responsibilities, commitments, and resource needs #2 (comment)) - Each focus rep would NOT be responsible for leading or managing individual projects; mainly keeping tabs on them on the roadmap (checking status, making sure they're active or even belong in our repo) and referencing active ones during the meetings (which is common practice if you've participated or observed some of the meetings in #marketing, #docs, #community-team, #training). As pointed out in Define and document process for running Sustainability Team meetings #20 (comment), there's even a meeting template we could repurpose.
• Complete Determine team roles, responsibilities, commitments, and resource needs #2 and post roles and needs in the handbook Improve Sustainability Team handbook #5
  • At the same time identify key roles we'd like to fill (in the same issue) and put a call out in meetings and related discussions; personally I think experienced mentors, GitHub savvy project managers, and docs leads will help alleviate the burden on team reps.
• Change the meeting day and time (if a goal is to make it easier for folks outside of EU timezones to become involved and contribute) Define and document process for running Sustainability Team meetings #20 (comment); assuming three reps are interested in claiming a particular focus area, we can finalize these roles/needs Determine team roles, responsibilities, commitments, and resource needs #2 and put a call out for folks to take on the responsibilities of coordinating meetings, note taking, and posting (detailed) summaries.
• Don't reference the entire issue tracker (https://github.com/WordPress/sustainability/issues) or even the roadmap (https://github.com/orgs/WordPress/projects/134) as the entry point for contributors. Once we have our own template (as previously suggested) the meeting coordinator can list individual projects and admin tasks.
• Clearly define and document the benefits (and incentives) for contributors in the handbook Improve Sustainability Team handbook #5

Thoughts?

[YellowlimeNL]

You address many and good topics here @gusaus. Knowing the team is strill growing and cannot deal with all suggestions at once, what's the topic you suggest to cover first? And what role do you see for yourself?

[gusaus]

I tried to reconcile and clarify the suggestions with @CeliGaroe's in the next comment thread. Considering every suggestion or task has been logged (as admin) and worked on/discussed during multiple meetings, there's nothing new or out of scope of team rep responsibilities (as defined/discussed in this P2 post).

With regards to my role(s), outside of creating/helping organize most of the admin issues, I've been spending most of my pledged time contributing to multiple projects on our roadmap (see the ones I've self assigned in the 'In Progress' or 'Contributing columns') and participating in related meetings and discussions across multiple teams.

As an umbrella issue for most of the active 'Economic' and 'Social' projects on our roadmap, I think our collaboration with the Contributor Working Group on Five for the Future #16 will help grow and sustain our team.

[CeliGaroe]

Here are my suggestions/thoughts:

• Creating issues:
  • Perhaps the person that creates an issue should stay directly involved on its work or resolution, or at least find a leading person for it before creating it. If not, some issues are opened and not worked on.
• Closing issues (for team reaps or issue leading person):
  • Set a time window to close or archive an issue if nothing has been done on it: 1-2 years?
• Adding issues to the roadmap (redirect new members from slack meetings and handbook only to it, not to the issues):
  • Before any person adds an issue to the roadmap, this issue should have a leading person or persons that are willing to work on it and move it forward. Having a person that can invest a bit of time in that issue helps set up what to do and how to do it in the issue's comments, what guide and facilitate new members to join.
  • Set a time window to remove an issue from the roadmap is it has been inactive too much: 6 months?

[YellowlimeNL]

Good points @CeliGaroe. I fully agree with you. Also with the length of periods you mention.

[gusaus]

@CeliGaroe I think these are great suggestions (and pretty well aligned with what I was suggesting in the previous comment thread).

I'll try to reconcile below:

Perhaps the person that creates an issue should stay directly involved on its work or resolution, or at least find a leading person for it before creating it. If not, some issues are opened and not worked on.

I think we have enough team reps to stay on top of this if we restructured roles/responsibilities as suggested above and related issues and discussions (like this P2 post).

Expectations for team reps can vary from team to team. In general, Sustainability team reps help to:

• prepare for and run the sustainability team’s weekly chats
• providing as-required updates to other contributor groups
• generally representing the sustainability team across the project, or in the occasional chat
• maintain a high-level perspective and awareness on current team projects

Team reps should expect to dedicate, at least, 1 to 2 hours per week to these activities. Any active sustainability contributor can be a team rep, and we can have more than two team reps.

As outlined in related issues and discussions, we should keep in mind that 'contributing to projects' is outside of the scope of responsibilities/allotted time. Even the tasks related to 'enabling/increasing' contributions (all labeled 'admin' ) can be assigned to other team members. Which, considering the processes and policies we're trying to determine (here and this related admin task #13) reside in the Sustainability Team handbook #5, is already happening!

[noraferreiros]

Sorry, I don't understand the relationship between Celi's suggestion and the Team Rep roles. In the sentence: "I think we have enough team reps to stay on top of this", what is "this"? Creating issues? Deciding the ones to close/archive? Assigning leaders to issues?

Just a note: let's be careful about comparing our incipient team with others that have been in operation for years, with people who dedicate 40 (or whichever) sponsored hours a week. Let's focus on and win one race at a time.

About your suggestion, Celi, I would lower the time to take out of the roadmap the inactive tasks. Maybe 3 or 4 months (change-of-season cleaning? ;D). And I'd also indicate somewhere to check the existing issues before opening a new one to include it on the roadmap. Otherwise, I fully agree with your suggestion. I especially support avoiding "someone else should do" tasks, and encourage contributors to take forward its own proposals.

[CeliGaroe]

I agree with you, Nora. I suggested very conservative time windows, but I am on favor of reducing them if that keeps the Roadmap easier to jump on for new (and not so new members). :) Your suggestion of inviting to check existing issues before opening a new one is a no brainer, I think we should add it for sure to the guidelines.

[gusaus]

This meaning the team rep responsibilities as described in this P2 post and related issue #2. So for the context of this discussion, just the following:

maintain a high-level perspective and awareness on current team projects

While any rep (like any other contributor) should be able create or contribute to a particular project, that is 'not' a requirement or responsibility. Would deciding the ones to close/archive be part of the responsibility? Probably yes, but not difficult to manage if 1) each rep had a particular focus area (as suggested here); 2) the processes and policies we're discussing here (and this related admin issue #13) are documented in the Sustainability Team Handbook #5; and 3) we create a meeting template #20 (comment) that will enable contributors running the weekly meeting (personally I don't think running meetings 'should' be a rep responsibility) to create a clear/consistent agenda that will surface active roadmap projects, along with active discussions, priority admin tasks.

@noraferreiros to your point:

let's be careful about comparing our incipient team with others that have been in operation for years, with people who dedicate 40 (or whichever) sponsored hours a week

As you've mentioned before, we're a bit of a Rara Avis when it comes to other Make Teams. While our scope seems large and daunting (especially to the relatively small group of reps and contributors able to participate during meetings), the reality is we own/manage a handful of projects (all active I think) and contributing to the rest (all owned by the Community Team I think).

The other thing we should all keep in mind is our team probably wouldn't be official if we didn't widen the scope to include projects focusing on Economic sustainability like #15. We can embrace that by identifying our resource needs in #2 and then using the funding tools and platforms to sustain ourselves!

[gusaus]

Referencing my agenda suggestion and subsequent discussion (in the Contributor Working Group repo) as I think joining forces with the Contributor Working Group (if it happens) should build team capacity (including help with weekly meetings and summaries) while enabling our four team reps to meet the previously defined expectations (referenced in this previous comment) without going over the allotted 1-2 hours/week.

Reason for this is the majority of projects could potentially be moved/merged into different repos and managed by other teams (including the following):

Contributing

• Refine and extend Five for the Future #16
• Enable/organize/contribute to NextGen and other Events related to Sustainability goals and focus areas #12
• Leverage and contribute to the Open Website Alliance #19
• Extend the do_action hackathon format #21
• Contribute to the Dashboard Initiative #10

In Progress

• Explore and enable options for funding community projects, teams, working groups, and contributors #15
• Leverage and Extend the FundOSS fundraising format #22
• Adopt and integrate Open Collective #24

Evaluating

• Refresh and revitalize the contributor and leadership pipelines #18
• Help connect and streamline collaboration between Make Teams and community contributors #14

In other words, the only projects in our repo might end up being the Environmental ones folks were focusing on before agreeing to expand the scope in order to become an official team.

• Create a draft to collect information about the efforts made by the WCEU’s organizers in favor of environmental sustainability. #33
• Reducing WordPress archive weight #30
• Input for the (WordCamp) handbook around sustainability #9
• Review sustainability tags used at WP Plugin directory #8

We'd still want to reference on https://github.com/orgs/WordPress/projects/134/views/1 but our reps would only be responsible for maintaining a high-level perspective and awareness (which can be easily done once 'the team' agrees upon a proper cadence #20 and the meeting template/format is implemented #34).

[gusaus]

After reading through this meeting discussion, I decided to transfer issues/projects (ideas or ones we don't own or manage) into discussions (https://github.com/WordPress/sustainability/discussions).

Seems like that would be more effective format for discussing 'how' team members can contribute (including referencing issues across multiple repos) while making our roadmap look much more manageable (especially after deleting the columns we no longer need).

If we can surface all admin issues, discussions and roadmap items during each meeting (should be easy once we complete #34) we'll be able to provide clear entry points for contributors w/o overwhelming our reps.