Category for design proposals

In the Wikimedia Commons project, we had @lozanaross involved as a designer, to propose workflows and wireframes for the integration. Towards the end of the project, we have been wondering how to better involve designers in our development processes beyond this particular project, and I would like to make some progress on this.

My impression is that GitHub issues were not so well suited to have design discussions: intuitively, it feels like a GitHub issue is better adapted to write a fairly focused and well-defined implementation task, after the design phase.

So I am wondering if we could have a Design category in the forum. We could start some threads there around various aspects of OpenRefine worth re-designing, exposing which use cases prompt that re-design. The problems could be of any size and flavour, for instance:

  • a better preferences page
  • column statistics
  • the reconciliation configuration dialog
  • error reporting for Wikibase upload
  • the records mode.

The hope would then be that design-minded people could come in and propose new workflows for those areas. To make that more likely, it would be nice to have (in our technical docs, for instance):

  • some general design guidelines that codify the current practices in the tool (how should a dialog be organized, what colors to use, and so on)
  • some pointers to easy to use tools to make rough wireframes.

Once a design proposal is supported by the community, we could create a GitHub issue about implementing that design. There is no guarantee that someone picks it up immediately of course, but it would make it much more likely that it gets worked on, I would say. In some cases, the implementation could be handed over to interns or newcomers who have less familiarity with the tool.

Please add a Design category. PLEASE. Posting a development topic that can then be moved to that new Design category.
Facets and accessibility of font size increases over the app - Using this forum - OpenRefine

Thanks! I have created the category, as a subcategory in the development category:

I plan to slowly migrate some discussions from the “design discussions” label on GitHub to there. I will try to pick well-scoped discussions to try and make this new category inviting.

@lozanaross suggested to me privately that we could also have a design equivalent of the “good first issue” label. The “good first issue” label currently intends to identify issues that can be tackled by developers who are new to the project, but that’s quite different for designers.

Currently the “design discussions” label is gathering issues where some design discussion is ongoing, which is not quite the same thing. Intuitively, we would pick issues for which:

  • a design proposal is needed to go forward
  • are reasonably small in scope, so that someone can understand the use cases without a ton of prior knowledge about OpenRefine
  • are consensual and popular (the feature request is clearly in scope of the project and is supported by others)

How should this label be named? “designer help needed” maybe?

Would the following issues be good candidates to be labeled?

You’d want to keep using good first issue or help wanted since that is how GitHub easily showcases issues to those looking to help open source when browsing/exploring in some views on GitHub. It’s also directly exposed anytime someone types in /contribute in the repo url.
https://github.com/OpenRefine/OpenRefine/contribute

There are mentions of this:

  1. Managing labels - GitHub Docs
  2. Encouraging helpful contributions to your project with labels - GitHub Docs
good first issue Indicates a good issue for first-time contributors
help wanted Indicates that a maintainer wants help on an issue or pull request

Problems:

  1. We should limit to only 10 good first issues as recommended. We have TOO MANY good first issues which need to be removed completely and instead have a more keen eye towards priority labels and use of help wanted if we really want help with an issue because it’s a higher priority, has broader community benefit (not niche), and is something core contributors are not likely to tackle themselves or desire to. I myself am guilty of adding the good first issues label in the wrong intended way in the past and so this needs cleanup.

So all the labels of an issue are exposed to first time contributors in those various views such as ui ux javascript jquery frontend etc. So we might just ensure we are using more useful labels for the issue to be quickly highlighted against a certain skill set or contributors area of interest. I.E. maybe ui is way too generic, but useful for us to easily label, but missing additional narrow labels directly for the issue itself, which might be a jquery issue or javascript bug we’d like to cleanup better but never had the time.

I think it would be better to initially narrow good first issue to those that can be tackled within a few hours or a day for a first time contributor, which is entirely the point…they are “easy” issues. In that light, we actually only have a handful of “easy” issues. help wanted is definitely where many of the ui issues would be additionally labeled.

Given that there is suddenly a big influx of people wanting to contribute design proposals, there is a more urgent need for a curated list of issues that are suitable for them. So I am creating a dedicated tag for that - we can reorganize this in another way later. Here it is: “design proposal needed” tag.