Request for Feedback: Make/Team Dashboards

Dashboards are more than just a collection of numbers and graphs; they are the pulse of a project. In the WordPress ecosystem, where collaboration and open-source principles guide us, dashboards can be a powerful team tool. Here’s why:

  • Improved visibility and communication: Dashboards can provide a centralized place for team members to view key metrics and data, such as the number of open and closed issues, the number of commits made, and the number of tests passed. This can help improve visibility and communication across the team and ensure everyone is aware of the progress. Additionally, this can show progress to those seeking opportunities to contribute where help is most needed.
  • Better decision-making: Dashboards can help teams make better decisions by giving them data-driven insights. This information can help them identify areas where they are doing well and where additional help is requested. 
  • Increased transparency: Dashboards can help increase transparency within the team by clarifying what is being worked on and what progress is being made. This can help to build trust and collaboration.

Which teams will be involved?

While feedback from all teams is needed, Sustainability and 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. teams are vital to this success.

Open-source sustainability is a multifaceted concept beyond just keeping a project alive. It’s about creating an ecosystem where the software, the community that builds it, and the organizations that rely on it can thrive long-term. 

The Sustainability Team can foster gathering information, identifying metrics, and partnering with the Meta Team on proposed tools to help us reach these goals.

Recap of progress thus far

Building stats dashboards is not a new idea; various contributor teams have considered the idea or have created proposals for the same in the past. Here’s a non-exhaustive summary of the work done so far. 

Feedback requests: Your Voice Matters

Examples of how other various open-source projects measure the health of their organizations can be found at https://chaoss.community/kbtopic/all-metrics/

  • Active contributors to WordPress:
    • What metrics would you like to see on a team dashboard? 
    • How would you use a team dashboard?
    • How do we help ourselves (and future contributors) determine the right metrics?
  • WordPress Team Reps:
    • What metrics would be most helpful for you to track to represent your team effectively?
    • What would help you make data-informed decisions or help you focus on your top priorities?
  • WordPress Project Leadership 
    • What metrics would you like to see on a team dashboard to help you make informed decisions about your project?
    • How would you use this data?
  • Hosts, Plugins, Themes, SaaS, and Extender Ecosystem: 
    • What metrics and statistics would you like to see from teams throughout the WordPress Project?
    • What data would help you support your customers? 
    • How would data help your organization contribute to WordPress?
    • What data do you want to know regarding how your organization contributes?
  • Agencies from solo entrepreneurs through enterprise agencies (& their customers):
    • What metrics would be most helpful for you to track to manage your team’s workload and deliver high-quality results to your clients?
    • What metrics might your customers want to know?
    • What data do you want to know or have visible regarding how you or your organization contributes?

Conclusion: The Community’s Role in Dashboard Success

Your feedback is not just welcomed; it’s essential. 

Dashboards can be a cornerstone in the success of open-source projects like WordPress. They can help us be more transparent, make better decisions, and ultimately, create a more robust and inclusive community.

We invite you to leave your thoughts, suggestions, and insights in the comments below. Your voice can help shape the future of dashboards within the WordPress community.

Please share your feedback by: Wednesday October 11, 2023

The following people contributed to this post: @harishanker

WordCamp US 2023 Q&A

WordCamp US 2023 convened from August 24 to 26 in Washington, D.C. Nearly 2,000 attendees gathered for two days of engaging sessions, learning, and community-building. Saturday’s agenda concluded with back-to-back keynotes by WordPress co-founder Matt Mullenweg and Executive Director Josepha Haden Chomphosy and a subsequent Q&A session. Read more about the event and watch recordings of the keynotes.

Watch the recording of the Q&A session from the WCUS keynotes by Matt & Josepha

As with past events, this post collects questions from in-person and online WCUS attendees that could not be addressed live—with answers from Josepha Haden Chomphosy and Matt Mullenweg. The community submitted some wonderful questions about all things WordPress and beyond. Due to the large volume of inquiries submitted, please note that a compilation of the list’s seven most representative and highly voted questions has been made. Tune in to the WordPress Briefing Podcast’s future episodes for answers to additional questions and discussion on related topics.

Let’s dig in!

Q. How do we ensure web accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) remains at the forefront of design innovation?

One of the things we learned in the Accessibility conversation during the Community Summit is that checklists and blocking requirements (while a great starting point) can only do so much. Accessibility requirements are more nuanced than that and require a fair amount of collective judgment. It was noted that there needs to be awareness and training of foundational concepts, like defining DOM order before visual order, defining desired functions before scoping projects, and generally being more intentional about testing things with users. This all, of course, has to happen in concert with contributors throughout the product development timeline so that what starts with our designers carries on through the development process as well.

Q. How can we better reach users/audiences unaware of WordPress or who looked at it five years ago but not recently?

The tactical answer here is that we need a couple of different brand campaigns: conquest and re-introduction. But since WordPress has overwhelmingly always relied on word of mouth marketing, it can be hard to coordinate that sort of effort. What we would have to do in order to accomplish this would be a grassroots drive for testimonials and such, then hope that we can generate a viral pattern in social media platforms. 

Q. How can we encourage developers to learn WordPress?

There are a few tactical answers that are always worth pursuing. We should find a way to partner with schools (especially at earlier ages) to introduce what WordPress can do. We should collaborate with organizations that already work directly with the groups of learners and developers we feel would benefit most from WordPress. And finally, we should invest in our self-serve learning platforms and event series. 

It also might be worth thinking through a shift in our mindset. It’s hard to predict the future, but we do know that there are skills and values that are useful for anyone early in their career. Advanced 21st century skills (esp critical thinking, cross-cultural communication, and time management) are going to be vital as more companies and opportunities are distributed, as well as an enterprising spirit to see and adapt to challenges as they arise; all of which you can learn in the WordPress project.

Q. As AI gets better with written/spoken language translation, how might that affect the direction of Multilingual WordPress support?

For starters, I want to be clear that I think applications of AI should always be guided by the question “how can we streamline or reduce menial tasks for people” and never by the question “how can we replace this person”. That being said, I think that any value of AI to multilingual activity in WordPress will primarily be on the Polyglot team side. I don’t think we can overstate the importance of having both a well-translated CMS and the opportunity for that CMS to natively host well-translated content as our world gets more connected. I do hope that we are able to take full advantage of the potential for shortened workflows in the work of translating elements inside the WordPress project. Between Translate Live and the opportunity to have human moderation of AI suggested translations, I hope to make WordPress more available across the world, but especially for locales that represent at-risk languages and therefore have no GTEs.

Q. How do you envision WordPress integrating with the Fediverse in the Future?

I love the idea of a bespoke, hyper-local social network that can take the place of group texts or any number of “friends only” implementations in current social media platforms—just you and your book club friends bloomscrolling through your latest gardening experiments!

I also think we have a handful of plugins and solo projects in the ecosystem that, with a little collaboration, could offer that to WordPress out of the box through a canonical/community 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.

Q. 1,000 plugins in the queue; is the Plugin Review team still growing?

It is! And if you want to learn more about contributing to the WordPress project in that way, you can apply to join us!

Q. What is the biggest opportunity for WordPress in the next decade?

I think the popular answer here is “Artificial Intelligence,” and of course, that is certainly an opportunity. But I think if we look at “opportunity” in the sense of “where we can grow the most” I will always say connecting to the communities we currently have the least connection to. More connections mean more knowledge shared, more skills honed, and more economic opportunities for this world (and web) that we hope to make into a better place.

Do you have a question? Comment below, and join one of the many teams making WordPress for answers.

#qa, #wcus2023

Proposal: Documentation translation / localization

¡Hola! WordPress features an extensive array of documentation, but it’s primarily available in English and distributed across multiple platforms. This poses a significant challenge, as over half of WordPress installations globally are in languages other than English. Consequently, many users cannot easily access documentation in their native tongue. So, how can we address this issue?

Current Status

The bulk of WordPress documentation resides on two primary websites: 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//documentation and developer.wordpress.org. While there are additional resources like manuals, tutorials, and forums, these two websites serve as the cornerstone for end-users, advanced users, and developers alike.

While some sections have been translated into other languages, the vast majority of this valuable content remains English-exclusive.

Final Objective

Given that over half of all WordPress installations are in languages other than English, our goal is to translate and sustainably maintain all the documentation in the world’s primary languages, with room for future expansion.

In the initial phase, we will focus on translating documentation tailored for end-users, advanced users, and developers. Subsequent stages will include additional resources such as Learn WordPress, Team Handbooks, and other related materials.

Previous discussions on the topic

Implementation Strategy

The method of achieving this monumental task is the proverbial million-dollar question. It has undergone extensive consideration, collaboration, and refinement across all involved teams. While it may not be the perfect plan, it is the most viable one we have arrived at after four iterative cycles of improvement.

Acknowledging that there are ongoing developments within the WordPress ecosystem, such as GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ Phase 3 and Phase 4. Although we’ve considered these, incorporating them at this stage is not feasible.

This proposal offers a realistic pathway to making WordPress documentation accessible to a global audience.

Centralizing Documentation Creation

The initial step in our strategy is to consolidate all documentation into a single, easily accessible location. Currently, the creation and discussion of documentation are scattered across various platforms such as Google Docs, GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, and WordPress itself.

To simplify maintenance and access, we have decided to host the foundational documentation on GitHub. Each segment of documentation will have its own dedicated repository, enabling individual teams to work in a more organized and efficient manner. This structure will also facilitate separate issue tracking and discussions for each repository, while allowing cross-repository conversation through project links.

Language-Specific Organization

To accommodate translations, each repository will feature folders named after the ISO codes of the languages into which the documentation will be translated. Initially, these folders will include “en” for English, and subsequently extend to other languages like “de” for German, “es” for Spanish, “fr” for French, and “it” for Italian.

Teams and Notifications

To stay abreast of changes in documentation, we’ll establish three tiers of teams that mirror the existing structure of the Polyglots community.

1. Repository Maintainers: These individuals will be responsible for the overall functionality of each repository. They will manage other teams and ensure that any updates are correctly implemented.

2. General Translation Editors (GTEGeneral Translation Editor General Translation Editor – One of the polyglots team leads in a geographic region https://make.wordpress.org/polyglots/teams/. Further information at https://make.wordpress.org/polyglots/handbook/glossary/#general-translation-editor.): GTEs will oversee each language-specific documentation group. Their role involves validating translations and ensuring their accuracy. There will be as many GTEs as there are languages to translate.

3. Translators: These contributors will carry out the actual translation work from one language to another.

When a change is made to any piece of documentation, the translators will receive notifications to update their translations accordingly. Should any language have pending translations, the respective managers will be alerted for validation and approval.

Those charged with high-level maintenance of the documentation will also keep track of the synchronization configurations between GitHub and WordPress, ensuring a seamless workflow and timely updates.

Translation Strategy

GlotPress, the WordPress built-in translation system, will not be used in this initiative to allow greater flexibility to adapt translations. The use of Machine Translation or Translation Memory will be at the discretion of the translators.

Given our scalability objectives, we’re focusing initially on translating into “general” language variants rather than “localized” ones. For example, we won’t distinguish between “Spanish from Spain” and “Spanish from Mexico,” or between “French from France” and “French from Canada.” Instead, our target is to cover the main languages spoken across all WordPress installations, with approximate percentage distributions as follows:

  • DE – German (6%)
  • EN – English (48%)
  • ES – Spanish (7%)
  • FR – French (5%)
  • IT – Italian (4%)
  • JA – Japanese (6%)
  • PT – Portuguese (5%)
  • RU – Russian (3%)

This coverage would extend to over 80% of existing WordPress installations.

Management for each translation team will occur through dedicated channels in the Global 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/. workspace (e.g., #docs-de). These channels will allow contributors worldwide to collaborate effectively. We’ll also establish translation guidelines for each language to ensure the text aligns with cultural norms and linguistic nuances, whether formal or informal.

Content Structure and Format

All documents will be stored in Markdown format, compatible with GitHub’s native editing capabilities. This ensures a user-friendly interface accessible via a web browser, although more advanced GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. users are free to use the tools they prefer for translation work.

Each document will feature an initial H1 headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. (or “#” in Markdown) that designates the document title, followed by a final H2 header (or “##” in Markdown) labeled “Changelog” to log major updates transparently.

The information architecture will mirror the URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org structure: language-specific folders will be followed by root files, which will contain an `index.md` and any additional folders or subfolders needed for organizing the content. This approach enables the use of localized URLs for each language, further enhancing accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility).

Publication Process

The final decision to publish documentation will rest with the maintainers of each respective project. Maintainers will have access to a configuration file, often referred to as a “manifest,” where they can list the Markdown files hosted on GitHub along with corresponding WordPress slugs, content architecture, and priority ranking for menu arrangement.

Furthermore, the manifest will specify the unique slugs, URLs, or identifiers for different languages. This enables a seamless transition between language versions, allowing users to switch easily from one to another. Once content is integrated into this manifest, it will automatically be converted from Markdown to HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. or the relevant 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. format.

The power of the global community

One of the revolutionary aspects of this system is its capacity to enable content creation directly in languages other than English. While this introduces a layer of complexity requiring coordination, it opens up new avenues for content generation. A contributor who may not be proficient in English but is fluent in French, Spanish, or Italian can now create original content.

In this way, the system empowers the community to produce content in a non-English language first, which can then be translated into English. This democratizes the content creation process and harnesses the talents of over half of WordPress users worldwide who are non-English speakers.

Challenges Ahead

While this proposal paints an optimistic picture, the implementation is far from simple. Numerous elements, including content management, translation coordination, technology interfaces, and overall project management, contribute to the intricacy of this initiative.

However, many of these challenges have already been anticipated, and others will undoubtedly emerge as the project progresses. One promising aspect is that once we successfully translate one repository, the subsequent translations should unfold more smoothly, given that the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. process remains consistent across all elements.

In essence, this initiative is an ambitious undertaking, but its scalability and adaptability make it a worthy challenge, promising significant benefits for the global WordPress community.

Just the Beginning: A Unified Vision for WordPress Documentation

As initially mentioned, WordPress documentation exists in a myriad of locations and formats. This project serves as a foundational step toward standardizing tools and practices. It aims to create a centralized repository where everyone knows where to find information, can trace the history of changes, and receives due credit for their contributions in both creating and translating content.

But the initiative goes beyond mere standardization. WordPress has a rich ecosystem that includes an expansive Lean WordPress site, replete with numerous manuals, tutorials, and community-driven projects. Each Make Team within the community has its body of documentation, offering insights into how our community operates. This is invaluable information that could benefit a wider audience, particularly those who may be deterred from participating because they lack proficiency in English.

As our community continues to grow, open and inclusive communication becomes increasingly vital. This initiative not only promotes that growth but also democratizes access to information. In doing so, it makes it possible for a more diverse range of individuals to engage with the community in meaningful ways, even in teams where language has previously been a barrier.

Thanks to @estelaris, @nullbyte, @milana_cap, @otto, @clorith, @kenshino, @coachbirgit, @femkreations for the review, proofreading and hours spent on this proposal.

#docs, #documentation, #i18n, #l10n