We've talked about this quite a bit in the context of DevHub where User Contributed Notes are occasionally used as a feedback mechanism. Basically, we need a way for docs consumers to report problems or suggest edits of published documentation on .org.

The initial proposal would be to build or use something akin to ​Post Forking on the front-end of handbooks and eventually other places like DevHub or HelpHub.

Personally I don't think an MVP has to be a complete solution, it mostly needs to cover the rift drawn between moving away from the Codex where any user could edit anything to the now largely closed systems on .org.

I think starting with the handbooks would be the way to go.

Plugin and theme authors currently have the power to mark threads as resolved within their own support forum, which is great.

Problem description However, some of the larger plugin/theme shops have a support team to help out on their own support forums. I think it would be useful to be able to recognize those people in the support forums, like we’re able to recognize authors.

Proposal So what I would like to propose is adding a new role: Plugin/Theme Support. Everyone with this role should have rights to mark topics within their own support forum as resolved, and should not be affected by posting speed limitations for their own support forum. This role should also show in the forums as ‘Support’, similar to author.

The reason why I propose a new role, instead of adding the capability to the contributor role is because, in my opinion, they serve a different purpose. Let me explain.

A contributor is someone who helped your open source project forward. This can be by providing feedback, writing code, creating images, doing marketing or being a friend of the project, for example.

Someone working on support does contribute his/her (paid) time to your project and is in that way a contributor. However, I think there are more than enough valid use cases where you don’t want someone who contributed code (for example) once to be able to close support request on behalf of the author.

That’s why I think having a separate support role would be viable. It would show the community that this person is vetted and answering on behalf of the plugin/theme author.

Related ticket This proposal is related to ticket #2598.

Managing support role Of course, it should be possible for plugin authors to manage the list of support people. I see two reasonable ways to do so, which should be mutually exclusive.

One way is by adding the usernames to the readme.txt file, the same way contributors are currently added. The other way would be to add users the same way committers are currently added, on the Advanced View of the plugin.

Showing support staff To be transparent about this, we’d probably also need a place to list people in the support role. This could be the Advanced View page, or even the plugin page itself.

Replace the contents of ​https://ps.w.org/robots.txt with:

User-agent: * Disallow: /

The RSS feeds generated by the new Plugin Directory platform have a number of drawbacks/defects compared to the feeds that were generated by the old platform.

1. When a new reply is posted to a topic:

• The "forum-level" feed (e.g. ​https://wordpress.org/support/plugin/media-library-assistant/feed) generates a copy of the initial post for the topic, with the initial date/time and author. This is almost useless; you have to go back to the forum to access the text of the update and see who posted it.

• The "topic-level" feed (e.g. ​https://wordpress.org/support/topic/importing-photoshop-iptc-data-into-wordpress/feed ) generates an update with the correct text, date/time and author.

• The email message generated for "subscribers" to the topic also has the correct information, but the message comes as plain-text so markup for code blocks, lists, etc. is lost.

2. When the original post in a topic was modified, the feed generates and ongoing stream of "updates" identical to the original except for the "This topic was modified 2 weeks, 6 days ago by ..." text. This makes it hard to identify topics with genuine updates.

3. When updates are posted to old topics (e.g. started 8 months ago), no RSS feed update is generated. It is hard to know when new activity occurs in an old topic.

Minor notes:

1. The subject line no longer includes the plugin name, which makes it harder to organize an archive by plugin.

2. The subject line no longer includes the post author, which would be fine if the actual author value was set correctly.

3. The subject line now identifies "[Resolved]" topics, but not any other status value.

In short, RSS updates should contain:

• The actual text of the update, with HTML markup
• The actual date/time of the update
• The actual author of the update
• A subject line that includes the plugin name and perhaps the current status in addition to the topic title.

• Change the <title> content to: {{Full Name}} ({{Username}}) - WordPress user profile | WordPress.org. E.g., Joost de Valk (joostdevalk) - WordPress user profile | WordPress.org.

• Add and populate a meta description tag with the (sanitized) content of the Bio field, up to 160 characters (cutting off gracefully with an ellipses character).

• Add and populate open graph tags as follows:

<meta property="og:type" content="profile" />
<meta property="og:title" content="{{Full Name}} - WordPress user profile" />
<meta property="og:description" content="{{Meta description}}" />
<meta property="og:url" content="{{URL}}" />
<meta property="og:site_name" content="WordPress" />
<meta property="og:image" content="{{Gravatar Large Image}}" />
<meta property="profile:username" content="{{Username}}" />

Profile badges don't seem to automatically appear for all areas. My core and plugins badges appeared on my profile on their own (as far as I can tell), but my Speaker badge had to be added manually with some difficulty, and my Meta badge hasn't appeared at all after getting first props a few weeks ago (see [2016]).

The following code should be adapted and added to profile templates (values from ​https://profiles.wordpress.org/jonoaldersonwp/ used for reference).

<script type="application/ld+json">
{
    "@context":"https://schema.org",
    "@graph":[
        {
            "@type":"Organization",
            "@id":"https://wordpress.org/#organization",
            "url":"https://wordpress.org/",
            "name":"WordPress",
            "logo":{
                "@type":"ImageObject",
                "@id":"https://wordpress.org/#logo",
                "url":"https://s.w.org/style/images/about/WordPress-logotype-wmark.png"
            },
            "sameAs":[
                "https://www.facebook.com/WordPress/",
                "https://twitter.com/WordPress",
                "https://en.wikipedia.org/wiki/WordPress"
            ]
        },
        {
            "@type":"WebSite",
            "@id":"https://wordpress.org/#website",
            "url":"https://wordpress.org/",
            "name":"WordPress.org",
            "publisher":{
                "@id":"https://wordpress.org/#organization"
            }
        },
        {
            "@type":["WebPage","ProfilePage"],
            "@id":"https://profiles.wordpress.org/jonoaldersonwp/",
            "url":"https://profiles.wordpress.org/jonoaldersonwp/",
            "inLanguage":"en",
            "name":"{{Page title}}",
            "description":"{{Meta description}}",
            "isPartOf":{
                "@id":"https://wordpress.org/#website"
            }
        },
          {
            "@type":"Person",
            "@id":"https://profiles.wordpress.org/jonoaldersonwp/#profile",
            "name":"Jono Alderson",
            "image":"https://secure.gravatar.com/avatar/beed0f5ca54ae221655b9f30a1f6fe66?s=200&#038;d=mm&#038;r=g",
            "jobTitle":"Special Ops",
            "worksFor": {
             "@type":"Organization",
             "name":"Yoast"
            },
            "sameAs": [
                "https://www.facebook.com/jonathan.alderson",
                "https://www.linkedin.com/in/jonoalderson/",
                "https://twitter.com/jonoalderson"
            ],
            "mainEntityOfPage": { "@id" : "https://profiles.wordpress.org/jonoaldersonwp/" }
        }
    ]
}
</script>

NOTE: Optional nodes (like worksFor) should only be included when the relevant profile fields are populated.

NOTE: https://meta.trac.wordpress.org/ticket/4277 changes the title and description contents; values here should also change and use the new values specified in #4277.

NOTE: https://meta.trac.wordpress.org/ticket/4278 is required to retrieve/set social profiles in the sameAs array.

NOTE: If name is not set, fall back to username.

The option "None" for Tickets >> Setup >> Predefined Account is unclear - this seems like there would be no payment gateway if that setting is chosen, which makes it unclear how you can access the custom gateway settings.

Changing this label to "Custom Account" or "Local Payment Account" would be clearer.

Hi guy's,

This is the first time I write a ticket here. Do not hesitate to give me advice if it is not the usual way to fill a ticket.

I would like to bring to your attention that there are problems about the layout on the website ​https://central.wordcamp.org/ for Opera users on Android.

Here is an example on this screenshot, but there are probably others :

I posted this info on slack yesterday and @coreymckrill recommended me filling a ticket here.

Regards, Jason

To save time and avoid typos, it would be great to support a means of that prefilling the coupon field.

For example: city.wordcamp.org/tickets?coupon=2017volunteer

Volunteers, sponsors, speakers, organizers, scholarship recipients, and others rely on coupon codes, and this would enable organizers to ensure they get the coupon code right on the first try.

If a ticket on bbPress or Meta Trac is closed with a particular resolution the resolution cannot be changed without reopening the ticket:

eg: bbPress Trac (Meta is identical):

BuddyPress and Core Tracs can change resolution withot reopening the ticket:

Taking a punt that the following code needs to be added to bbPress and Meta Trac "workflow-*.ini" files. I know bbPress and BuddyPress "workflow-*.ini" files are yet to be open sourced, presuming the same for meta:

Via: https://meta.trac.wordpress.org/browser/sites/trunk/trac.wordpress.org/conf/workflow-core.ini#L64

# Once the ticket is closed
# - reopen
# - change the resolution to something else
...
...

change_resolution = closed -> closed
change_resolution.name = change the resolution, set
change_resolution.operations = set_resolution
change_resolution.permissions = TICKET_EDIT_DESCRIPTION
change_resolution.default = -31

Aside: It wouldn't hurt to add the "mark as duplicate" section also ;)

Trac has been directing people to an error page when they try to submit comments or updates to tickets. I first seen this problem mentioned on March 30th.

The message reads Missing or invalid form token. Secure cookies are enabled, you must use https to submit forms..

The submissions are coming from pages that are https in the browser though and cookies are enabled.

It would be helpful if the forums logged who marked a post resolved (or unresovled) as well as closed etc.

From a moderator perspective, this would help track down plugin developers (for example) who automate resolving tickets. It would also mean we'd know who to ping if someone closed a post without a comment.

Example:

• Marked Resolved by Mika 11 Jan 2017, 22:00
• Marked unresolved by Otto 11 Jan 2017, 22:30

or

• Closed by Jan 13 Feb 2017, 11:30
• Opened by Marius 14 Feb 2017, 00:13

While we were building the new bbPress theme we discovered that the WordPress theme live on ​https://wordpress.org/news/ would've been the best starting point. We now had to hack together stuff from various places.

Wouldn't it make sense to open-source that theme used at /news/ as well?

"Skip links" are one of the most simple and better known ways to improve accessibility for keyboard users and assistive technologies users. They allow to bypass blocks of content that are repeated on multiple pages, typically: navigation menus.

They're implemented since years in WordPress core and the bundled themes. They're also part of the WCAG recommendation:

Success Criterion 2.4.1 Bypass Blocks ​https://www.w3.org/TR/WCAG21/#bypass-blocks

In order to be effective, a skip link used to bypass the top navigation needs to:

• be the first focusable element in a page
• be revealed on focus
• point to the main content in the page

Far from pretending to be a complete analysis of all the .org network pages, I've gone through the main pages linked in the main navigation menus. To recap:

• Home: no skip link
• Showcase: no skip link
• Themes: no skip link
• Plugins: skip link is not the first focusable element
• Mobile: no skip link
• Support: skip link is not the first focusable element
• Get involved (Make): no skip link
• About: skip link is not the first focusable element and it doesn't appear on focus (conflicts with clip-path: inset(50%); inherited by social-icons.css)
• Blog: no skip link
• Hosting: no skip link

I realize the .org network is made of different templates coming from different sources and I guess it's a complicated setup. However, it would be great to make sure the skip to content link is actually present in all pages and works properly.

On some locales (like Catalan), most of the translations are done by 3-4 people (with 2 of them being GTE), even if according to ​https://translate.wordpress.org/locale/ca there are 10 GTE, and almost a 100 contributors.

This is a problem not only because it simply doesn't scale (with the amount of strings that themes & plugins have, 3-4 people are not enough), but also because is extremely hard for GTEs to identify "active" contributors to help and guide them so they become one day GTE, and for contributors to find active GTE so their strings get approved and don't stay forever as pending.

Ideally, there should be a way of "filtering" the teams page (​https://make.wordpress.org/polyglots/teams/?locale=ca) with some kind of "active" filter, with active being a rule such as "has translated/reviewed more than X strings (could be 0) in the last 3-4 months".

That could help to really asses the health of a team, as you could quickly identify how many people is actively contributing to the project.

Also, if that filter included some kind of aggregated cross-project stats (similar to the ones you get "per-project" in translate.wp.org), pointing to the projects they contributed, it would be easier to "measure" the amount of contributions people is doing: I, as a GTE, am more in validating strings translated by someone who contributes regularly than strings from someone who only translated 1 string two months ago. Computing such a huge amount of stats won't be light in terms of resources, but in order to be useful, these stats don't need to be "live": a weekly update would be more than enough to get a sense of the current state.

This would also give extra visibility to the health of the team, on top of the "activeness" filter: knowing there are 100 people active when 99 of them only have translated one string isn't a sign of healthy at all.

To provide debugging information some users post their full logs in a reply. These can be up to 10k lines which makes reading the page really annoying because you have to scroll like 5 minutes.

Examples:

• ​https://wordpress.org/support/topic/qtranslate-x-compatibility-2/#post-8250157
• ​https://wordpress.org/support/topic/no-confirmation-email-received-2/#post-8235539

I suggest to prevent posting replies which have more than X chars/words/lines and to recommend using a service like Pastebin or GitHub gists.