Categorization of Work on the proposals page

[tkrieck]

Hi everybody,

I would like to start a discussion about the Proposals page (design.xwiki.org), more specifically about the “Type” field and its use.

This discussion started originally about how to see all available proposals about UI/UX (or that are in the stage of UI/UX definition). A “Master” page was originally proposed, but that would lead to some problems, specially duplication of work to keep the page updated.

So, what would be needed is a way of filtering the proposals page to only show UI/UX ones.

We have the “Design” type, but it is not about UI/UX and more about Architecture. Now, when discussing this in the XS chat it was pointed out to me that “Type” should be a progress indicator, meaning that a proposal is evolving during its lifecycle.

I believe the order is (@vmassol correct me if I’m wrong):

1 - start as a Requirement,
2 - move on to Design (architecture),
3 - then Implementation.

The “Feature” type in this POV is a bit weird, and I am not sure about its original meaning.

There’s also the question about parallel work being done, as UI/UX can evolve together with Architectural decisions (and can even change in the Implementation phase).

UI/UX is akin to Requirements, but not every Requirement is a UI/UX one, so this type alone could not be used. We could create a new one though as “UX/UI Definition” or any other term that fits the proposal.

As this is a brainstorm, I will not propose something set in stone, because honestly I lack the full understanding of the “Type” field and its use in the project.

I’d welcome your input on this.

[CharpentierLucas]

@tkrieck

This discussion started originally about how to see all available proposals about UI/UX (or that are in the stage of UI/UX definition). A “Master” page was originally proposed, but that would lead to some problems, specially duplication of work to keep the page updated.

So, what would be needed is a way of filtering the proposals page to only show UI/UX ones.

We have the “Design” type, but it is not about UI/UX and more about Architecture. Now, when discussing this in the XS chat it was pointed out to me that “Type” should be a progress indicator, meaning that a proposal is evolving during its lifecycle.

AFAIU after looking a bit more at the proposal object, we should already have a way to filter given the info is up to date, but those filters are far from quick to figure out and not very reliable if we don’t keep all the proposals updated.

My idea on what we discussed yesterday was to have a page with pre-filled out filters for the few use case we have frequently. It would definitely not need to be a landing page but it would be a good util to avoid losing time finding filters (or the favourite you spent time to setup with the right query)

With Add a new "Accepted" xproperty on design.xwiki.org we added the accepted field but it’s not always used:

https://design.xwiki.org/xwiki/bin/view/Main/WebHome#

I’ll try to come up with a personal checklist of things to do when starting the implementation of an agreed UI/UX update so that I don’t forget any info to add and it’s easy to follow where the implementation is.

Thanks Thiago!

[vmassol]

So my POV is that the current type property is a mess…

It’s a mess because it’s not even a progress indicator since Feature cannot be positioned before or after the other possible values…

Also, a proposal is very often about different things: design, requirements, implementation. And it evolves as the proposal progresses.

So I think what we could do is repurpose the type field to be a multi-value static list of possible values which would indicate what the proposal is about:

• ui → a proposal about UI
• api → a proposal about APIs
• design
• implementation
• requirements
• feature

WDYT?

@tkrieck would that match your need of:

how to see all available proposals about UI/UX (or that are in the stage of UI/UX definition)

?

Could you explain your real need? What I’m proposing above would allow to see all proposals that are about UI changes.

Also, if you check ui + design, you could list all UI proposals that have some design in them.

Do you really need to see only proposals in the stage of UI/UX definition? If so, why?

Thanks

[vmassol]

@CharpentierLucas

With Add a new “Accepted” xproperty on design.xwiki.org we added the accepted field but it’s not always used:

Why not? It’s supposed to be always used. If not, we need to fix the proposals that have been accepted but not marked as such.

[vmassol]

@CharpentierLucas

I’ll try to come up with a personal checklist of things to do when starting the implementation of an agreed UI/UX update so that I don’t forget any info to add and it’s easy to follow where the implementation is.

I’ve tried to improve the process described on the home page: https://design.xwiki.org/xwiki/bin/view/Main/?viewer=changes&rev1=14.2&rev2=15.1&

Thx

[tkrieck]

@vmassol

@tkrieck would that match your need of:

It would yes.

@vmassol

Could you explain your real need? What I’m proposing above would allow to see all proposals that are about UI changes.

Simplicity of finding UI/UX proposals by anyone (with a shareable URL with filter set, for example) that way is easy also for stakeholders to find proposed work. Currently, for any stakeholder to find these proposals it is necessary to filter the proposals by name or author, and it is prone to error and fiddling too much with filters. This also makes it easier for devs to find the proposals that have been accepted and can be implemented.

@vmassol

Why not? It’s supposed to be always used. If not, we need to fix the proposals that have been accepted but not marked as such.

A bit unrelated, but currently, the default for the field is “No". So it gives the impression that many proposals have not been accepted, but many are just being discussed still and haven’t been updated. I need to get through my list of proposals to check this.