Several ​HTML5 sectioning elements automatically create ​ARIA landmark regions.

Landmark regions are exposed to assistive technologies and allow users to quickly find information in a page. Ideally, all content in a web page should be wrapped within landmark regions. For now, I'd like to propose to focus on the navigation menu.

In this specific case it's important to know that <nav> elements are mapped to an ARIA role=navigation. Therefore, <nav> elements are perceived by screen readers and users can jump to them using dedicated keyboard shortcuts.

In the wp.org network, some sections don't use <nav> elements at all. For example, the home page (screenshot from Safari and VoiceOver):

Other sections do use navigation landmarks but not for the main menu. For example, the Themes section has two of them:

Same in the Plugin section sub-pages:

For clarity, these are respectively:

• a <nav> element with a role="navigation": it was common practice to repeat the role even if redundant, to support old browsers assistive technologies
• a <div> element with a role="navigation", which is equivalent to a <nav>

Besides technical details, the most important navigation (the main one) doesn't use a navigation landmark. Wrapping the main menu in a <nav> element would be a good, simple, improvement.

Note: when in a page there are multiple landmarks of the same type, it's important to use an aria-label to help users to distinguish them. This is also what WordPress core and the bundled themes do.

Suggested:

• wrap the existing main menu markup in a <nav aria-label="Main menu">
• where present, add to the secondary navigation an aria-label="Secondary menu" (or any better wording)
• the toolbar already uses an aria-label="Toolbar", no need for any change

Optionally:

• modernize the markup: remove role="navigation" and just use a <nav> element

Note about the wording: When screen readers encounter a <nav> element or a role="navigation", they already announce "navigation": it's recommended to not use this word in the aria-label because it would be announced twice.

If you use the search bar on ​https://wordpress.org/support, you will see that it neither includes HelpHub articles nor excludes Codex ones.

I feel that we should well be

1. including HelpHub in it and
2. adding a tab for specific search
3. removing Codex indexing

Also, search bar should say "Search documentation and forums" or something along those lines and not just forums?

Releated discussion in Slack ​https://wordpress.slack.com/archives/C02RP4WU5/p1543850975111100

When a user wraps text in their forum posts with "<li>" tags - The layout of the page breaks.

For an example of this see - ​http://wordpress.org/support/topic/please-ignore-just-testing-something?replies=1#post-4430248

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.

When subscribed to a Make blog, the email sent when a post is published has a link called "See all comments", and it has a fragment ID of #comments. But there is no ID in the post named comments, so the link just takes you to the top of the post. The other link, for commenting, is to #respond, which does exist and works fine.

Here is an example from the email ​https://make.wordpress.org/core/2019/04/25/site-health-check-in-5-2/#comments

Plugin pages, like ​https://wordpress.org/plugins/autoptimize/, often contain FAQ content.

When this is the case, we should output FAQ schema markup, with an aim to encourage Google to show FAQ questions+answers in the search results (therefore achieving extra visibility and clickthrough-rates).

Approach

• Add an additional node to the existing schema markup on plugin pages, for "@type": "FAQPage".

• Add a mainEntity property to house the questions.
  • Loop through each question/answer, and construct a Question node with an acceptedAnswer property.

Example output

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "What does the plugin do to help speed up my site?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "It concatenates all scripts and styles, minifies and compresses them, adds expires headers, caches them, and moves styles to the page head, and scripts (optionally) to the footer. It also minifies the HTML code itself, making your page really lightweight."
    }
  }, {
    "@type": "Question",
    "name": "But I’m on HTTP/2, so I don’t need Autoptimize?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "HTTP/2 is a great step forward for sure, reducing the impact of multiple requests from the same server significantly by using the same connection to perform several concurrent requests. That being said, <a href="http://engineering.khanacademy.org/posts/js-packaging-http2.htm">concatenation of CSS/ JS can still make a lot of sense</a>, as described in <a href="https://css-tricks.com/http2-real-world-performance-test-analysis/">this css-tricks.com article</a> and this <a href="http://calendar.perfplanet.com/2015/packaging-for-performance/">blogpost from one of the Ebay engineers</a>. The conclusion; configure, test, reconfigure, retest, tweak and look what works best in your context. Maybe it’s just HTTP/2, maybe it’s HTTP/2 + aggregation and minification, maybe it’s HTTP/2 + minification (which AO can do as well, simply untick the “aggregate JS-files” and/ or “aggregate CSS-files” options). And Autoptimize can do a lot more then “just” optimizing your JS &amp; CSS off course 😉"
    }
  }, {
    "@type": "Question",
    "name": "Will this work with my blog?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Although Autoptimize comes without any warranties, it will in general work flawlessly if you configure it correctly. See “Troubleshooting” below for info on how to configure in case of problems."
    }
  },
  {...}
  ]
}

Sanitization concerns

All HTML tags should be stripped from fields, with the exception of the text property of an acceptedAnswer, which should:

• Accept <a>, <strong> and <em> tags.
• Disallow/remove any values/properties/attributes of these tags (other than the href attribute on <a> tags).
• Remove invalid markup (e.g., an <a> without a closing </a>).

• 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}}" />

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":"ProfilePage",
            "@id":"https://profiles.wordpress.org/jonoaldersonwp/#webpage",
            "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/#webpage" }
        }
    ]
}
</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.

The default page title structure on wordpress.org is {{NAME}} | WordPress.org. E.g., ​https://wordpress.org/about/swag/ has a title of Swag | WordPress.org

On Rosetta pages, the structure is {{LOCALE}} « {{NAME}} — WordPress. This should be changed to {{NAME}} | WordPress.org ({{COUNTRYCODE}}). E.g., Accessoires | WordPress.org (FR)

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 ;)

E.g.,

​http://pingomatic.com/ should redirect to ​https://pingomatic.com/ ​http://pingomatic.com/stats/?cat=dog should redirect to ​https://pingomatic.com/stats/?cat=dog

When a video is published, a tweet is sent from ​https://twitter.com/WordPressTV The current picture used by the tweet is just a black box. It would be nicer to use the Video Thumbnail as image for twitter.

This is done in themes, but needs to happen in plugins as well.

If someone uploads a plugin with a proposed slug that is already in use, we need to have the plugin FAIL. This would prevent people from uploading their free plugin with the same name as their pro one and goofing all their users.

The breakpoint should be 50 users.

This would also need a tool on the admin end so we can see what's going on (much like we have for author cards). This WILL NOT fix a problem if we manually rename a slug per their request, but if we have the tool at least we'll be able to see why :/

E.g., ​https://wordpress.org/support/view/plugin-committer/corylamleorg should 301 to ​https://wordpress.org/support/view/plugin-committer/corylamleorg/

​https://wordpress.org/support/view/plugin-committer/corylamleorg/page/2 should 301 to ​https://wordpress.org/support/view/plugin-committer/corylamleorg/page/2/.

​https://wordpress.org/support/view/no-replies should 301 to ​https://wordpress.org/support/view/no-replies/

There are a couple problems with our current data set. They're not strictly related to each other, but I'm creating a single ticket for this because I'm guessing that the solution to both will be the same: switch from our current data source to a better one.

• Problem #1: Incorrect IPv4 results. No data source will be perfect, but [several online database had correct results for instances where ours weren't ​https://make.wordpress.org/core/2017/04/14/nearby-wordpress-events/#comment-32448].
• Problem #2: No IPv6 support. Without this, the results will quickly lose effectiveness. As of May 2017, ​IPv6 adoption is at 18% globally and rising relatively fast. Some countries are as high as 32%.

It looks like our database was updated recently (March 2017), but I can't find any info on where the original data comes from. @dd32, @tellyworth, do either of you know? Do you have any thoughts on other potential sources?

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?

The following legacy pages should be deleted, and 301'd to a sensible location. May also need removing from nav, if this isn't automatic. Likely going to need to do a few passes of these for ones I miss in the initial sweep... Might also be some duplicates.

'Welcome' flavours (should 301 to site root): ​https://fuc.wordpress.org/txt-welcome/ ​https://frp.wordpress.org/txt-welcome/ ​https://kab.wordpress.org/txt-welcome/ ​https://tg.wordpress.org/txt-welcome/ ​https://li.wordpress.org/txt-welcome/ ​https://nl.wordpress.org/txt-welcome/ ​https://tt.wordpress.org/txt-welcome/ ​https://la.wordpress.org/txt-welcome/ ​https://la.wordpress.org/txt-welcome/ ​https://si.wordpress.org/txt-welcome/ ​https://am.wordpress.org/txt-welcome/ ​https://es-cr.wordpress.org/txt-welcome/ ​https://lin.wordpress.org/txt-welcome/ ​https://sq.wordpress.org/txt-welcome/ ​https://es-ar.wordpress.org/txt-welcome/ ​https://oci.wordpress.org/txt-welcome/ ​https://br.wordpress.org/txt-welcome/ ​https://de-ch.wordpress.org/txt-welcome/ ​https://cn.wordpress.org/txt-welcome/ ​https://nb.wordpress.org/txt-welcome/ ​https://bre.wordpress.org/txt-welcome/ ​https://gd.wordpress.org/txt-welcome/ ​https://el.wordpress.org/txt-welcome/ ​https://hr.wordpress.org/txt-welcome/ ​https://cs.wordpress.org/txt-welcome/ ​https://es-mx.wordpress.org/txt-welcome/ ​https://is.wordpress.org/txt-welcome/ ​https://bg.wordpress.org/txt-welcome/ ​https://it.wordpress.org/txt-welcome/ ​https://it.wordpress.org/txt-welcome/logowordcamp/ ​https://lv.wordpress.org/txt-welcome/ ​https://bn.wordpress.org/txt-welcome/ ​https://ms.wordpress.org/txt-welcome/ ​https://fy.wordpress.org/txt-welcome/ ​https://uz.wordpress.org/txt-welcome/ ​https://ug.wordpress.org/txt-welcome/ ​https://as.wordpress.org/txt-welcome/ ​https://mr.wordpress.org/txt-welcome/ ​https://ky.wordpress.org/txt-welcome/ ​https://dv.wordpress.org/txt-welcome/

'Install' flavours (should 301 to the local 'download' page if it exists, and the root if not): ​https://rhg.wordpress.org/txt-install/ ​https://en-gb.wordpress.org/txt-install/ ​https://ku.wordpress.org/txt-install-2/ ​https://fr.wordpress.org/txt-install/ ​https://da.wordpress.org/txt-install/ ​https://li.wordpress.org/txt-install/ ​https://el.wordpress.org/txt-install/ ​https://eu.wordpress.org/txt-install/ ​https://srd.wordpress.org/txt-install/ ​https://so.wordpress.org/txt-install/ ​https://so.wordpress.org/txt-install/ ​https://kab.wordpress.org/txt-install/ ​https://tw.wordpress.org/txt-install/ ​https://fi.wordpress.org/txt-install/ ​https://haz.wordpress.org/txt-install/ ​https://de-ch.wordpress.org/txt-install/ ​https://os.wordpress.org/txt-install/ ​https://es-ar.wordpress.org/txt-install/ ​https://mr.wordpress.org/txt-install/ ​https://es-mx.wordpress.org/txt-install/ ​https://es-co.wordpress.org/txt-install/ ​https://gl.wordpress.org/txt-install/ ​https://nn.wordpress.org/txt-install/ ​https://jv.wordpress.org/txt-install/ ​https://mk.wordpress.org/txt-install/ ​https://fy.wordpress.org/txt-install/ ​https://id.wordpress.org/txt-install/ ​https://ido.wordpress.org/txt-install/ ​https://ms.wordpress.org/txt-install/ ​https://sw.wordpress.org/txt-install/ ​https://ca.wordpress.org/txt-install/ ​https://kn.wordpress.org/txt-install/ ​https://azb.wordpress.org/txt-install/ ​https://sq.wordpress.org/txt-install/ ​https://tl.wordpress.org/txt-install/ ​https://zh-hk.wordpress.org/txt-install/ ​https://es-cr.wordpress.org/txt-install/ ​https://pl.wordpress.org/txt-install/ ​https://ko.wordpress.org/txt-install/ ​https://oci.wordpress.org/txt-install/ ​https://ky.wordpress.org/txt-install/ ​https://fa-af.wordpress.org/txt-install/ ​https://th.wordpress.org/txt-install/ ​https://bn.wordpress.org/txt-install/ ​https://as.wordpress.org/txt-install/ ​https://pan.wordpress.org/txt-install/ ​https://az-tr.wordpress.org/txt-install/ ​https://lin.wordpress.org/txt-install/ ​https://vi.wordpress.org/txt-install/ ​https://fr-be.wordpress.org/txt-install/ ​https://ka.wordpress.org/txt-install/ ​https://xho.wordpress.org/txt-install/ ​https://hu.wordpress.org/txt-install/ ​https://fr-ca.wordpress.org/txt-install/ ​https://is.wordpress.org/txt-install/ ​https://dzo.wordpress.org/txt-install/ ​https://sv.wordpress.org/txt-install/ ​https://ko.wordpress.org/txt-install/ ​https://sr.wordpress.org/txt-install/ ​https://co.wordpress.org/txt-install/ ​https://bre.wordpress.org/txt-install/ ​https://hr.wordpress.org/txt-install/ ​https://hr.wordpress.org/txt-install/clean-install/ ​https://hr.wordpress.org/txt-install/upgrade/ ​https://gu.wordpress.org/txt-install/ ​https://km.wordpress.org/txt-install/ ​https://ar.wordpress.org/txt-install/ ​https://fa.wordpress.org/txt-install/ ​https://it.wordpress.org/txt-install/ ​https://su.wordpress.org/txt-install/ ​https://tuk.wordpress.org/txt-install/ ​https://sa.wordpress.org/txt-install/ ​https://bs.wordpress.org/txt-install/ ​https://kir.wordpress.org/txt-install/ ​https://yor.wordpress.org/txt-install/ ​https://br.wordpress.org/txt-install/ ​https://nb.wordpress.org/txt-install/ ​https://tt.wordpress.org/txt-install/ ​https://ta.wordpress.org/txt-install/ ​https://uk.wordpress.org/txt-install/ ​https://snd.wordpress.org/txt-install/ ​https://arq.wordpress.org/txt-install/ ​https://tg.wordpress.org/txt-install/ ​https://twd.wordpress.org/txt-install/ ​https://eo.wordpress.org/txt-install/ ​https://ur.wordpress.org/txt-install/ ​https://hr.wordpress.org/txt-install/clean-install/ ​https://ug.wordpress.org/txt-install/ ​https://bcc.wordpress.org/txt-install/ ​https://khk.wordpress.org/txt-install/ ​https://ory.wordpress.org/txt-install/

'Themes' themes ​https://ml.wordpress.org/Themes/

'Sample page' variants ​https://snd.wordpress.org/sample-page/ ​https://tzm.wordpress.org/sample-page/ ​https://rup.wordpress.org/sample-page/ ​https://az-tr.wordpress.org/sample-page/ ​https://os.wordpress.org/sample-page/ ​https://lin.wordpress.org/sample-page/ ​https://twd.wordpress.org/sample-page/ ​https://fur.wordpress.org/sample-page/ ​https://sa.wordpress.org/sample-page/ ​https://pan.wordpress.org/sample-page/ ​https://la.wordpress.org/sample-page/ ​https://as.wordpress.org/sample-page/ ​https://bre.wordpress.org/sample-page/ ​https://fuc.wordpress.org/sample-page/ ​https://tt.wordpress.org/sample-page/ ​https://azb.wordpress.org/sample-page/

'Releases' variants ​https://cs.wordpress.org/releases/

'Contact' variants ​https://es-pr.wordpress.org/contact/ ​https://ur.wordpress.org/contact/ ​https://kal.wordpress.org/contact/ ​https://eu.wordpress.org/argitaraketak/ ​https://dzo.wordpress.org/contact/ ​https://scn.wordpress.org/contact/ ​https://ps.wordpress.org/contact/ ​https://es-mx.wordpress.org/contact/ ​https://km.wordpress.org/contact/ ​https://tah.wordpress.org/contact/ ​https://ta.wordpress.org/contact/ ​https://snd.wordpress.org/contact/ ​https://kir.wordpress.org/contact/ ​https://sna.wordpress.org/contact/ ​https://dv.wordpress.org/contact/ ​https://rhg.wordpress.org/contact/ ​https://mlt.wordpress.org/kuntatt/ ​https://frp.wordpress.org/contact/ ​https://yor.wordpress.org/contact/ ​https://arq.wordpress.org/contact/ ​https://sa.wordpress.org/contact/ ​https://oci.wordpress.org/contact/ ​https://ido.wordpress.org/contact/ ​https://lo.wordpress.org/contact/ ​https://rup.wordpress.org/contact/ ​https://la.wordpress.org/contact/ ​https://fao.wordpress.org/contact/ ​https://kn.wordpress.org/contact/ ​https://me.wordpress.org/contact/ ​https://os.wordpress.org/contact/ ​https://li.wordpress.org/contact/ ​https://twd.wordpress.org/contact/ ​https://es-ar.wordpress.org/contact/ ​https://as.wordpress.org/contact/ ​https://ltz.wordpress.org/contact/ ​https://pan.wordpress.org/contact/ ​https://mya.wordpress.org/contact/ ​https://en-gb.wordpress.org/contact/ ​https://ory.wordpress.org/contact/ ​https://az.wordpress.org/contact/ ​https://tg.wordpress.org/contact/ ​https://te.wordpress.org/contact/ ​https://mri.wordpress.org/contact/ ​https://khk.wordpress.org/contact/ ​https://kin.wordpress.org/contact/ ​https://tuk.wordpress.org/contact/ ​https://az-tr.wordpress.org/contact/ ​https://mk.wordpress.org/contact/ ​https://ast.wordpress.org/contact/ ​https://gu.wordpress.org/contact/ ​https://bre.wordpress.org/contact/ ​https://am.wordpress.org/contact/ ​https://mg.wordpress.org/contact/ ​https://mr.wordpress.org/contact/ ​https://lin.wordpress.org/contact/ ​https://hat.wordpress.org/contact/ ​https://ary.wordpress.org/contact/ ​https://co.wordpress.org/contact/

E.g., ​https://codex.wordpress.org/Special:Contributions/Jany2786@gmail.com

This template should have a meta robots value of 'noindex, follow'.

The per_page argument for the Plugins API query_plugins action seems to return the wrong number of results in some cases.

So, if you limit the per_page to 20, you only get 19 items back event though that there are more than 20 results available.

We are hitting this issue with the WP-CLI plugin search command, which shows the exact count of elements returned. See ​https://github.com/wp-cli/extension-command/issues/156 for the related issue.

Currently Stats_Report (plugins/plugin-directory/tools/class-stats-report.php) checks SupportPress

We've moved so we'll need to update those checks to use (I think) the API for HelpScout

​https://developer.helpscout.com/mailbox-api/endpoints/conversations/list/

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.

Quite often we're sharing code snippets to help our users when providing support. I would love to see the support forums support syntax highlighting. In it's current implementation it's not incredibly helpful to the end user.

Here's an example: ​https://wordpress.org/support/topic/reorder-posts-in-collection?replies=4

Since people are getting more and more used to slack and markdown and the three backticks for code blocks, we should consider supporting that in bbPress