designsimply 5:43 am on July 9, 2018
Tags: core-editor ( 718 ), gutenberg ( 494 )

Labeling Issues in the Gutenberg Project

Hello! I will be working closely with 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/ for the next several months and am really pleased to be here!! My WordPress username is designsimply and I go by sheri 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/..

Part of my work is centered around bugbug A 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. gardening where my goal is to scrub bugs to fit the project’s workflow in a way that saves everyone else time by adding screenshots, checking validity, closing inactives, and sane labeling. Labels are important for historical reference too, so any work here should prove useful as the project grows!

Labeling rules I tend to follow:

Each issue should have a focus area and type label.
Each PR should have a focus area and status label.
Priority labels should only be set as needed—just using high and low is 👍.
High priority issues should have an assignee or be in an active milestone.
Action-based labels start with “Needs”.

I’ve made a few small changes to labels so far:

Added [Type] Duplicate (for tracking and so dupes can easily be filtered out of searches).
Combined [Type] Support and [Type] How do I? and renamed to [Type] Help Request.

Have I mentioned I love labels?! Let’s update them together as an iterative process. Deciding labels can be opinionated so open discussions about them will be fun and help us work together in good ways.

My next questions about labels:

Can we move Chrome and UI Components to something like Block Controls?
Can we move [Type] Plugin / Theme Interoperability to [Type] Plugin Conflict and [Type] Theme Conflict?
Should Won't Fix and Works For Me be [Type] labels?
I’d love to add Design Notes label as a way to track design decisions.
What is [Type] WP Core Bug for exactly?
Should Text Mode be changed to Edit as HTML to match the UIUI User interface?
Can we get rid of [Status] Stale in favor of closing?
Let’s use [Status] Needs More Info or close with a comment instead of Works For Me.
Would it be useful for devs to add [Status] Revisit to issues that are not good to keep open now but may be good to look at again in the future?

If you’re keen to help with Gutenberg bug gardening or discuss the inner amazingnesses of labeling 😊, then I would love to talk with you! Please comment here or say hello in #core-editor on Slack.

#gutenberg

gziolo 6:42 am on July 9, 2018

Can we get rid of [Status] Stale in favor of closing?

The idea behind this label was to give the author a week or two to update PR before closing it. We can also remove this label and close such PRs with a note to reopen when someone wants to continue working on it.
- designsimply 2:30 pm on July 9, 2018
  
  Ace! I like that flow because we can use it as a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for closed issues later too. Thank you for commenting!
- Brandon Payton 6:19 pm on July 9, 2018
  
  We can also remove this label and close such PRs with a note to reopen when someone wants to continue working on it.
  
  What do you think of keeping the [Status] Stale label when closing? That would give us the ability to search for things that were closed because they were stale.
Andrew Duthie 12:36 pm on July 9, 2018

Can we move Chrome and UIUI User interface Components to something like 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. Controls?

“Chrome” was originally meant to encompass parts of the UI which wouldn’t fall neatly under other labels, such as the heading bar, sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., etc. So I’m not sure “Block Controls” works well for this purpose, though I could imagine some other descriptor for miscellaneous UI issues (“Editor UI”?).

Can we move [Type] 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 / Theme Interoperability to [Type] Plugin Conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. and [Type] Theme Conflict?

A point here is that often the interoperability issues are applicable to either a theme or a plugin, it just happens to be that one particular plugin or theme had surfaced the issue. If it’s an issue of label name length, even just shortening it to “Plugin Interoperability” could be okay, even still applying it to theme issues.

Should Won’t Fix and Works For Me be [Type] labels?

I’ve personally never used these labels. They’d seem more like “Status” . Also, I’d assume there’s a decent amount of overlap between the latter and “Needs More Info” (maybe even eliminate in favor of).

What is [Type] WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Bug for exactly?

My assumption upon seeing this label would be to expect there is a corresponding TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. issue reflecting an issue that can’t be remedied within 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/ directly, and requires an upstream change from WordPress itself. That the Gutenberg issue stays open is questionable: We could “close in favor of” the Trac issue; or maybe it is nice to have the Gutenberg issue stay open so long as the upstream ticketticket Created for both bug reports and feature development on the bug tracker. is unresolved.

Should Text Mode be changed to Edit as HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. to match the UI?

I’d have assumed this is referring to the “Code Editor” editing mode, though the fact that it’s ambiguous also speaks volumes on its own. Certainly should be updated, even at least to “Code Editor”.

Can we get rid of [Status] Stale in favor of closing?

This is an interesting proposition. As @gziolo mentioned, it is used as a prompt to give the original author an opportunity to update. But I’m also open to the idea of being more proactive with closing, so long as we acknowledge as a community that issues and pull requests can easily be reopened, and as long as reopening doesn’t require some burden or dependency on a maintainer to do so (at least if this becomes unreliable).

Let’s use [Status] Needs More Info or close with a comment instead of Works For Me.

Agree.

Would it be useful for devs to add [Status] Revisit to issues that are not good to keep open now but may be good to look at again in the future?

I think so. There’s also the ideas project which was meant to serve this purpose as well, though I don’t know that it sees much use.
- designsimply 2:55 pm on July 9, 2018
  Thank you so much for the feedback!
  
  On [Type] Plugin / Theme Interoperability, great points there, does [Type] Plugin / Theme Conflict work just as well? My reasons = shorter & more clear.
  
  Changelog:
  - Added Chrome description: “Parts of the UIUI User interface which don’t fall neatly under other labels.”
  - Added [Type] Plugin / Theme Interoperability description: “Interoperability issues applicable to either a theme or a 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.”
  - Renamed Won't Fix to [Status] Won't Fix.
  - Added [Type] WP Core Bug description: “Requires an upstream change from WordPress.”
  - Renamed Text Mode to Code Editor and added description: “Sometimes referred to as Text Mode.”
  - Added [Status] Stale description: “Gives the original author opportunity to update before closing. Can be reopened as needed.”
  - Removed Works For Me in favor of [Status] Needs More Info.
Tammie Lister 2:10 pm on July 9, 2018

> Can we move Chrome and UIUI User interface Components to something like 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. Controls?

In this case I don’t think so as it’s not all about controlling blocks.
Can we get rid of [Status] Stale in favor of closing?

I would be very up for getting rid of stale.
Should Won’t Fix and Works For Me be [Type] labels?

To me they are status not types?
Would it be useful for devs to add [Status] Revisit to issues that are not good to keep open now but may be good to look at again in the future

I don’t think so let’s use the ideas project for this as not a super common case right now. Worth noting not just devs use labelling and as a result the ideas project works for everyone.
I’d love to add Design Notes label as a way to track design decisions.

There isn’t a need for this as far as I can see. We have design decisions getting made on actual issues, no need to add another label there this time.
What is [Type] WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Bug for exactly?

As said on this one it should totally have a correlating tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. log.
- designsimply 3:13 pm on July 9, 2018
  Awesome! Thank you for commenting. Sweet:
  - Added a description for Chrome.
  - Keeping [Status] Stale for a little while longer, added a description.
  - Tabling [Status] Revisit for now.
  - Ah! I was thinking of Design Notes for actual issues—to indicate it’s something that’s contains a design decision worth reading, for example, you are new the project. Might be more work than it’s worth. 🙂
  - Added a description for [Type] WP Core.
Ajit Bohra 2:27 pm on July 9, 2018
```
Chrome
```
I personally find it confusing, initially, I thought it’s for some chrome browser related. My bad!

Lately, have been reading WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ handbook and loved the labels documentation
https://make.wordpress.org/cli/handbook/repository-management/#labels

it would be helpful if we can expand this further
https://wordpress.org/gutenberg/handbook/reference/repository-management/#labels

Most of the labels are self-descriptive still it would be good to add descriptions to them on 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/.

Have noticed we have a workflow around certain labels it would be helpful to document the same.

We have few labels which indicate issues are actionable. Will be helpful to add them to contributing doc.

Label Suggestion:
Does it make sense to add new label [Status] Has PR to quickly identify. Will be helpful for contributors when picking up issues.

or do we use [Status] In Progress for the same ?
- designsimply 4:03 pm on July 9, 2018
  
  Great suggestions! I really love when documentation appears where you need it when you need it, and in this case the descriptions for labels in the 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/ project fit that model. I submitted a PR to update the handbook in 7831. 😁
  
  Agreed about documenting some of the more specific labeling workflows. Can we raise that issue at the next #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor meeting?
  
  On [Status] Has PR, I am fond of [Status] Needs Review which is typically could be used for issues with PRs but also for PRs which need review but don’t have a specific reviewer request. I see [Status] In Progress as something someone is actively working on but that is not yet ready for review.
  - Ajit Bohra 5:01 pm on July 9, 2018
    
    sure let’s discuss further at the next #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-editor meeting
    - designsimply 5:08 pm on July 9, 2018
      
      ❤️
  - designsimply 5:08 pm on July 9, 2018
    Changelog:
    
    Added Accessibility description: “Changes that impact 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) and need corresponding review (e.g. markup changes).”
    
    Added Needs Design Feedback description: “Changes that modify the design or user experience and need sign-off.”
    
    Added [Type] Bug description: “An existing feature is broken.”
    
    Added [Type] Enhancement description: “A suggestion for improvement.”
    
    Added [Status] Needs More Info description: “Typically requires follow-up from the original reporter in order to be actionable and relevant.”
designsimply 4:20 pm on July 9, 2018
Changelog:
- Added description for [Type] Help Request: ‘Requests for help with setup, implementation, or “How do I?” questions.’
- Added description for [Type] Question: “Questions about the design or development of the editor.”

Comments are closed.

Welcome!

Communication

Labeling Issues in the Gutenberg Project

Welcome!

Communication

Share this: