Announcement of a new Support Team meeting time

This post is to announce a change in the timing of our regular Support Team meetings. 

The next meeting will be held at on Thursday, April 11, 2024, at 20:00 UTC in #forums on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. (a Slack account is required) or at https://make.wordpress.org/support/chat/. Subsequent meetings will be held every 2 weeks at the same time.

If it’s been a while since you joined a support meeting, or you’re thinking of joining for the first time (welcome!) here’s a few things for you to know.

  • Ordinarily, the agenda for the meeting will be published on the Monday preceding the meeting itself. Y’all are welcome to suggest agenda items in the comments of that post.
  • Everyone is welcome to attend! Help out answering questions in the forums and want to get more involved? Want to see how things in the Support Team work? Whatever your reason, we’d love to have you join us.
  • Decisions on items (which are added to the agenda) are made by those who are in attendance at the meeting, with any comments on the agenda itself taken into account.

The agenda for our next meeting will be out on April 8th and I look forward to seeing you all on April 11th!

Discussion on changes needed for Forums to adhere to the Digital Services Act (DSA)

Following my previous findings/messages in Make SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. – here are some changes we may need to make to the forums in order to adhere to the Digital Services Act (DSA) and make life easier for the Incident Report Team (IRT):

Notifying users when content is archived

One thing we will need to start doing is notifying forum users when we archive their content. It is a requirement (on legal advice) that this notification be clear about why the content is being archived (ie. the guideline that is being broken). There’s two ways I can see that we could address this:

Existing method:

Currently we will often reply to the user within the thread – explaining the reason why their comment/thread is being archived. When we mention the user they should be notified of that reply (challenges with email delivery notwithstanding).

If we were to have a system/process in place which made sure all mods include a clear explanation in their reply for why the thread/message was archived – then this would likely fulfil our responsibility.

Adding a ‘Reason’ dropdown/field to the ‘Archive’ button

If it were possible to add functionality to the ‘Archive’ button then we could:

  • Have the option to select the ‘reason’ from a dropdown list and/or
  • Have a text field prompt to write the reason
  • Send an email to the user with notification of the message being archived, and the reason.

Something like this leaves less margin for error, but does require development work by the MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team.

Notifying users when they are blocked

There is also a requirement that when a user is blocked they are notified of this, including the reason for being blocked. We currently would add a user note with the reason, but this isn’t necessarily sent to the user as a notification.

It would be worth investigating if we can either:

  • Automatically send a notification to the user when they are blocked, and include the most recent user note as a reason, or:
  • Have a form for when we blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. a user which includes a dropdown (for common reasons) and/or a freeform field to add a reason – and when that is submitted the user is notified and the details are added to the user notes.

Either of these cases would require development work from Meta.

A note on Spam

It is important to note that these new regulations do not apply to spam. We will not need to notify in anyway for spam messages that are archived/deleted, or spammers that are blocked.

Improved User Notes

These requirements also make it a great time to discuss our use of User Notes more generally.

Looking towards the future it is important that any user notes we add are clear and understandable to other Mods (both now and into the future when we may not be around to clarify) and also to the Incident Response Team (IRT) if they are required to check user notes for any investigations.

My recommendation would be that we work to ensure our User Notes are clear, free from jargon and personal commentary, and verbose about the action being taken and why.

I don’t wish to place undue burden on the mods to have to reply in a specific format or anything like this – but there is value in remembering that any User Note you add will need to be useful to others in the future (sometimes in the long future) and writing with the appropriate level of clarity and objectivity.

Next Steps

I’m interested in discussion about these issues and how we can ensure we fulfil our legal responsibilities in a way that both minimizes work for Mods, but also provides a user-friendly experience to those in the forums who are effected by our actions.

I’ll leave this post open for 2 weeks for discussion and then summarise the results, along with next steps to implement any changes, following that period.

Should mods delete links on topics when requested?

Hi, everyone. I would like to discuss a proposal to change how we handle requests to remove links on the forums.

The issue

We often have the following issues on forums:

  1. Someone creates a topic and adds a link — they might add the link directly to the topic content (or alternatively use the “page I need help with” field).
  2. This same person realizes that the link is publicly available (and often indexed by Google when added directly to the content), so they don’t want the link on the topic and ask moderators to remove it.
  3. As this is something covered in our guidelines, our moderators deny these requests (unless there is a safety reason for removing them), and this can sometimes trigger long discussions between everyone involved.
  4. Sometimes, these folks even contact the DPO mailbox to discuss this further.

Proposal

While I’m not trying to justify OP’s (original poster) reasons and definitely not recommending us to change it because of GDPR (we’re technically allowed to keep these links), I believe we should change the workflow because of the following reasons:

  • We should stop spending all this time arguing with people — it would take us 10 seconds to remove the links instead of 20 minutes arguing about it.
  • It would improve OP’s experience on the forums — it is always good to make people happy when we can.

With that in mind, I would like to recommend we start manually deleting links on new requests as an experiment. If this doesn’t work out, we can document the reasons and revert this idea (or explore automated options for doing the same thing).

How do you feel about it?

X-post: Training Team Update – February 2024

X-comment from +make.wordpress.org/updates: Comment on Training Team Update – February 2024

22nd February Support Team meeting

The support meeting will be held on Thursday, February 22 2024, 19:00 UTC in #forums on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.(a Slack account is required) or at https://make.wordpress.org/support/chat/.

Commercial support quality in reviews

Following on from the recent change to guidelines around reviews of Commercial/Pro plugins we need to discuss and make a decision about whether quality of support received for Commercial/Pro plugins is a valid part of a review.

Support Team plans for 2024

Let’s discuss my proposal of some things to work on in 2024 to make the Support Team more sustainable for the long term, and better connect with our contributors who work in the Forums.

Firmer language around links in reviews

Even though it shouldn’t be possible for link – some folks do manage to do so. At the moment our wording around that guideline (in the form itself) is a little soft. Should we have a clear mention in the Guidelines themselves, and also update the wording in the form to be clearer?

Checking in with international liaisons

This is the section where we reach out to the non-English speaking parts of our community, to see how they are doing, if there’s anything we can help each other with, or just interesting things going on that it would be nice to share with others.

There’s no requirements for previous participation or “fame” to share here, anyone is welcome, and we encourage newcomers to participate!

Unable to make the meeting, or maybe meetings just aren’t your thing? We would still love to hear how things are going in other non-English speaking parts of our community. Please feel free to let us know via the comment section below, in your own time, if there is anything you’d like to share, any questions or concerns you have, or just to let us know you’re doing OK!

We will make a habit of putting this callout with every agenda post going forward, so that everyone has a chance to join in.

For any other items to discuss, please add them to the comments below, or bring them up in the meeting.

#forums

Guideline change: Reviews of Commercial/Pro Plugins

As discussed at https://make.wordpress.org/support/2024/02/suggestion-for-a-change-in-the-guidelines/, the forums team met on Slack on Feb. 8 and agreed to the change in the guideline regarding commercial reviews.

The paragraph currently reads

Reviews of plugins and themes are to be limited to the functionality of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ and the support provided by the authors for the versions of the plugins/themes hosted on WordPress.org. 

That sentence will be replaced with

Reviews of commercial plugins/themes are acceptable on wordpress.org when such reviews discuss functionality or user-facing features. Reviews that are essentially payment disputes or are used to leverage support will be archived, with a reply that such disputes should be handled via private email.

Essentially, if it’s about WordPress, the review is OK. If it’s about the process of purchasing, subscribing, or supporting the paid plugin, then a review is not OK.

Various what-if scenarios we discussed on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

The plugins document will be updated in the near future.

Some proposed improvements for 2024

Hi folks – over the New Year period I was reflecting a little on the Support Team and the legacy of work we have there supporting the community in the Forums. I’ve also detected (and outright been told as well) that there’s the potential of some burnout within the team – which is something that (from a personal point of view) I don’t want any folks to go through.

I also think that there’s lots to learn from the Plugins Team and their work over the last 12 months in building a new team, documenting the way they work, and ultimately setting the team up to be sustainable for the long term.

TLDR: I’d like to propose that in 2024 the Support Team looks to set ourselves up for long term success and sustainability by taking stock of where we are today, expanding the team in a scalable way, and fostering more of a community amongst contributors who volunteer in the forums.

I’ve expanded that thinking into a few different areas that I’d like to raise for consideration in upcoming Team Meetings:

Taking Stock of current state of the team and documenting our work
One of the massive ongoing successes of the team is that the ‘work’ is continuously getting done in a timely fashion. We have no backlog, few complaints, nor any pressure to improve ‘performance’ of any kind – because of the great work y’all do.

But at the same time there is much of the work that is done which is unknown or undocumented. There’s plenty of great (and important) work which is done to keep the forums clean and tidy – which isn’t documented in the handbook. Speaking from personal experience I can say this makes it tricky to know exactly what work I can help out with – beyond the basics in the handbook. It also makes it hard to know what size the team needs to be to handle that workload sustainably.

One thing I’d propose is that we properly document these kind of things – to make decisions about team size easier, and to aid onboarding of potential new team members.

Team Size and Members

  • Team size (including Rosetta Forum mods)
  • An estimation of the amount of time spent on moderator tasks

Team Tasks: What is it the team actually does (and how)

  • Responding in #Forums
  • Pending, Spam, and Modlook queues of Forums
  • Proactively looking for Spam? (how?)
  • Proactively looking for sock puppets? (how?)
  • Password Reset queue (We could definitely do with better documentation of this)

Team Mission and Goals

  • What does success look like? What are we aiming for?

Expanding the team in a sustainable and scalable way
Having a better understanding of the tasks needed, and the bandwidth of the team will allow us to know when adding new team members is needed. As a step to reduce burnout and have a sustainability plan for the team – I propose a need to add a number of new team members within the next 3 months as a starting point.

Some things we will need to consider in order to do that:

Hiring and Recruitment process

  • Take learnings from the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Review Team and their recruitment
  • Design and implement recruitment and vetting (if needed) processes

Onboarding for new members

  • Review existing handbook and documentation.
  • Addition of Onboarding items to cover security, data management, and conflict resolution.

Introducing/participating in Mentoring opportunities

  • Have team members take part in the existing Mentor programs – providing a pathway for contributors towards joining the team.
  • Identify candidates amongst existing Forum contributors to invite to ‘officially’ join the team via a mentorship program.

Fostering a Community of Contributors in the Forums
At times the work of the Support Team could be considered to be in something of a ‘defensive’ stance – reacting to activity in order to keep bad actors away and maintain the integrity of the forums. This is important work – but I think we also have an opportunity to take a more proactive role in encouraging the contributors who give their time to answer questions in the general forums.

There’s even an opportunity to help them form something of a community around their work supporting users, and a potential funnel into Support Team membership if desired.

I don’t have any specific proposal for this – but I do have a few random ideas. And I’d love the team to consider if these kinds of initiatives could be helpful in taking an ‘offensive’ approach to improving the quality and usefulness of the forums.

  • We could look at having different ‘format’ meetings which encouraged contributors in the forums to be involved in a more social setting (the Learn Team is a great example of how they manage this whilst still having functional/practical meetings too).
  • We could produce a learn.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ course which guides contributors through some learning about ‘soft’ support skills like empathy and tone.
  • We could utilise the mentorship program to encourage and equip those contributors to do better (and more) work answering questions in the forums.
  • Investigate reaching out to those who are listed with pledged time towards support in an effort to activate them.

Supporting the Support team for another 20 years
All these ideas are towards the idea of having systems in place which mean the team will outlive the tenure of any of us in the team – in a way where it will continue to flourish, grow, and make the forums a safe and useful space for those needing support with WordPress.

I’m really excited to hear from y’all on the overall idea, but also the specifics that are proposed.


I’ll leave this post open for Comment for us to discuss and make some decisions at the Team meeting on 22nd Feb.

X-post: Incident Response Team: Call for Nominations

X-comment from +make.wordpress.org/project: Comment on Incident Response Team: Call for Nominations

Suggestion for a change in the guidelines:

The current guidelines for commercial products state that “Reviews of plugins and themes are to be limited to the functionality of the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or theme hosted on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/”. Therefore, moderators should remove reviews that discuss commercial versions and educate reviewers approrpriately.
Unfortunately, we usually only see commercial reviews when they’re pointed out, via the report topic tool, by developers/authors. More unfortunately, I’ve noticed that such reports occur, in the vast majority, for one star reviews. I have never seen a five star review reported.
As a result, we are removing one-star reviews and leaving the non-reported ones alone. This skews the average rating by limiting the distribution of stars to the higher levels.
I propose that we revise our guideline to say that reviews of commercial plugins/themes are acceptable on wordpress.org when such reviews discuss functionality or user-facing features. Reviews that are essentially payment disputes or support extortion would continue to be archived, with a reply that such disputes should be handled via private email.

X-post: Call for Mentees & Mentors: Contributor Mentorship Program Cohort #2 (2024 Q1)

X-comment from +make.wordpress.org/community: Comment on Call for Mentees & Mentors: Contributor Mentorship Program Cohort #2 (2024 Q1)