The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
three articles almost finished, and waiting for finalization post-review, and adding at the bottom excerptExcerptAn excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox., categories, and credits.
thanked @webcommsat for doing a thorough review on these as blogblog(versus network, site) test pieces and sharing all these in GitHubGitHubGitHub 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 picking up the points that also need to be added / discussed for tips for writers. Longer discussion on what in the review process needs to change / be clarified or set out from this learning from test reviews. More on this later in this post.
For the marketing launch:
have four posts and a few pages: they are not yet published, they are in public preview. Justin is working on performance with blockBlockBlock 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. themes, and other is on CSSCSSCascading Style Sheets. styles available to theme devs.
don’t have is anything to do with PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and backend.
JBossenger finishing converting short codes to blocks.
Due date for posts for go live was October 26, 2022
Three posts of four were completed for publication by the deadline
Soft launch: November 14-20, 2022 In this week after GutenbergGutenbergThe 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/, probably Thursday, or if articles are published earlier, then Wednesday. @bph advised all A8C contributors involved are on a retreat next week and so no work on dev coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. blog etc from them will be possible during that time.
The Welcome Post, About Page, How to Contribute, Writing for Tips. Three of four are completed. Writers are adjusting content and items discussions as part of the review process.
Dec 1, 2022 – next editorial meeting, will solicit feedback on additional content.
Week of Nov 28 – Dec 4, 2022: Official Release post draft for news section.
Developer blog repo on GitHub
There are areas for discussions, ideas and projects.
The Developer Blog Content Board (screenshot below) now has views for: progress, status.
During the meeting on November 3, 2023, new columns, labels were added to the Core Developer Blog Content Board. A status view was added to show both status and labels. A future column under discussion – Learn WordPress. This would be to assist the Training Team in knowing what may potentially be already covered in the dev blog or could be reused with a retarget of materials for LearnWordPress.org
Agreed every post should link to documentation and to Learn WordPress.orgWordPress.orgThe 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/ where one exists. If a Learn WordPress item is added later, this can be added where relevant and adds value to a blog through revisionsRevisionsThe WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision..
In the future, hope to be able to use the Revisions PluginPluginA 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. Revisions should be marked up in the revision plugin and on the GitHub card.
Props on GitHub tickets
This was discussed for what was needed. @webcommsat referred to the work that has been shared in core about efforts to standardize this across core/ the project and to assist with automation of credit. @desrosj is involved with this. @bph added that as this is work in progress, for the betaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. launch of the core dev blog, props would not be added to the end of a GitHub ticketticketCreated for both bug reports and feature development on the bug tracker. when closing it.
Once the guidelines on how to write the props are available, this can be added. It was agreed that this could be done retrospectively for posts that have already been published.
Action: nothing at present, once core/ project wide process is ready
Review process
Where to make major comments on text
Agreed more information was needed on the review process flow, building and revising from the process at the last meeting in light of having content to test. As reviewing and editing differs greatly across the project, an approach to apply specifically to the core dev blog has been confirmed to make it easier and clearer for both writers and reviewers.
In the case of these ‘test’ posts, no draft google document existed to add comments in suggestion mode. They were already in the CMS, as flagged at the earlier meeting. New posts also do not benefit from the use of the revision plugin, and the only option was to see the old versus the new in the CMS.
Actions:To go forward, for the dev blog we will use the GitHub ticket for anything which would be a bigger change of content. This will then need to be followed up by the writer. If further discussion is needed, writers should use the reviewer’s GitHub ID in the reply. The ticket can be a discussion area as there is no easy way to do this on the CMS itself for new posts.
Next step after feedback on a draft post:
Incorporate the feedback/ further discussion
Further discussion on how opinion in posts
As in the review testing process, it showed greater clarity was needed in this area for future writers and reviewers.
‘Opinion’ has different interpretations in editing. It does not mean a piece has to be bland or lifeless. Try to take care when writing a reflective comment like ‘what could have been done’ so that it does not inadvertently read or be misread as criticism in standard posts, eg be misread as the team missed this, or should have done…(that is, opinion free).
Personality of the writer is not the same as opinion, and this can still come out in the writing style.
Where posts/ articles are case studies, then ‘I’ can be used.
Action: To be clarified if “In my view, …” approach would be appropriate for non case study posts
Color contrast
Graphics in one article (the color contrast was hard to read).
Colors used for screenshots and light and dark mode.
Considering ways to avoid colors of text/ arrows etc which may be difficult to see or have limited color contrast.
Discussion on bringing together some tips for writing / graphics for accessibilityAccessibilityAccessibility (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).
Style guide discussions
Ongoing from the last meeting, further discussion on the style to be used in examples identified in the review of the initial content pieces.
Style guides
A variety exist within the project. In addition, an updated style guide and brand guidelines is in progress in the Marketing Team.
to add this to the open query on the tips for writers doc
Agreed that for writers and reviewers, they just need to know which style guide to check against and for this to be easy to do.
For specific queries, the following was agreed:
references to ‘frontend’ in computing should be ‘front end’
Credits on posts
There is a mixture of use within the project as a whole, where they are shown at all. Agreed in all pages and post, the credit/props:
will be right aligned,
italics, and
includes everyone who is involved with it through using their WordPress.org username.
Action: add style to use to tips for writers doc
Labels and categories discussion
This has been summarized in an updated note from the October 6, 2022 meeting below.
Next steps for soft launch of the Dev Blog:
outcome of items discussed being added to the tips for writers document, and after any reformatting, the GitHub card to be marked for ready for review label
‘How to contribute’ page: this is in progress. @bph is drafting this and will share it with the editorial group for review
nothing much else needed for soft launch
on-site navigation: bph working on that and get some comments from stakeholders.
how to contribute page: in progress
Next meeting
Agreed due to the limited attendance at the video meetings, that these meetings will be held in SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. as chat meetings which will also allow those in different time zones to comment asynchronously in the threads. This will also avoid the burden on someone to make notes from a video meeting or recording.
The next meeting will be on: December 1, 2022, at 13:00 UTC in the core-dev-blog channel of the Make WordPress Slack.
