Proposal for a new and simplified component structure for issues in Monorail

[Edwin Kempin]

Dear community,

Matthias, Nasser and I want to propose a new and simplified component structure for issues in Monorail.

What are the issues that we have with the current component structure?

• We have a confusingly large number of components and for users reporting issues it's unclear to which component an issue should be assigned.
• Some component names are not easily understandable by people that do not interact with the project on a regular basis, e.g. 'PolyGerrit' (means "Frontend"), 'pgm' (means "programs"), 'ESC' (means "Engineering Steering Committee").
• The component names are inconsistent, e.g. we have a mix of CamelCase (e.g. 'TestCoverage'), lowerscore_underscore (e.g. 'e2e_tests'), lowercase-hyphen (e.g. 'gerrit-installer').
• Many components have little or no usage (e.g. less than 5 issues).
• 42% of our issues have no component set.

To clean this up we want to propose a new and simplified component structure:

• Reduce the number of components (use hotlists to group issues by topic if needed).
• Make component names more verbose to make them easier to understand by users.
• Agree on a consistent naming.

Our proposal:

Use CamelCase unless the component name is the name of a plugin or app in which case we use that exact casing of the plugin/app.

Proposed components:

• Backend (include the existing 'Backend' component, replaces 'Backend>REST', 'Backend>accounts', 'Backend>accounts>external-ids', 'Backend>auth', 'Backend>caching', 'Backend>change-edits', 'Backend>diff', 'Backend>git-operations', 'Backend>groups', 'Backend>init', 'Backend>mail', 'Backend>permissions', 'Backend>pgm', 'Backend>queries', 'Backend>submit', 'Backend>topics', 'Backend>validation', 'LDAP', 'Lucene', 'NoteDb', 'SSHDaemon', 'Submodules', 'TestCoverage' (if the issue is about fixing test coverage for existing code), 'plugins>PluginInfrastructure')
• Frontend (replaces 'PolyGerrit')
• UX (replaces 'PolyGerrit>UX', includes any issues with workflows not just UI)
• Community (same as the existing 'Community' component)
• SteeringCommittee (replaces 'ESC')
• Documentation (replaces 'docs')
• Build (includes the existing 'Build' component, replaces 'TestCoverage' (if the issue is about infrastructure to measure test coverage))
• CI (replaces 'Build>CI')
• Homepage (same as the existing 'Homepage' component)
• Plugins (replaces 'plugins', subcomponents stay the same as they match the name of the plugins, e.g. 'plugins>accounts' becomes 'Plugins>accounts', except 'plugins>PluginInfrastructure' which becomes 'Backend')
• Applications (replaces 'apps', subcomponents stay the same as they match the name of the apps, e.g. 'apps>analytics-etl' becomes 'Applications>analytics-etl', 'gerrit-installer' becomes 'Applications/gerrit-installer')
• Modules>ElasticSearch (replaces 'ElasticSearch')
• Deployment (replaces 'aws-gerrit', 'docker-gerrit')
• Testing>e2e-tests (replaces 'e2e_tests')
• googlesource (issues triaged by the Gerrit backend team at Google, we will keep this component for now, but intent to replace it later with 'Backend' and a 'googlesource' hotlist)

At a later stage we may make setting a component mandatory. All issues without a component will be assigned to the 'Backend' component then.

Please let us know if you have any concerns with applying the new component structure.

Thanks,
Edwin on behalf of the community managers

[Ben Rohlfs]

Great initiative, thanks! +1

"Frontend" is a term sometimes used for the web server, as well. So we were trying to replace "polygerrit" rather with "web" or "web application". But I am not sure and don't have a strong opinion on what the best component name is here. Maybe "Frontend & WebApplication" or just "WebApplication"?

Optional nit: You could maybe further combine:

- Build&CI into one

- Documentation&Homepage into one

- Plugins&Applications&Modules into one: Maybe with some forcing function to set a subcomponent and for the subcomponent to match a repo name?

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/CACA_R4%2BNvgG8nm3K6jkxA1D5sE%3DZgBVu7V_KgdM4Mr8dvQNmeQ%40mail.gmail.com.

[Sven Selberg]

Some counter-nits, without any strong opinion.

On Friday, June 10, 2022 at 11:20:54 AM UTC+2 bro...@google.com wrote:

Great initiative, thanks! +1

"Frontend" is a term sometimes used for the web server, as well. So we were trying to replace "polygerrit" rather with "web" or "web application". But I am not sure and don't have a strong opinion on what the best component name is here. Maybe "Frontend & WebApplication" or just "WebApplication"?

Optional nit: You could maybe further combine:

- Build&CI into one

IIUC 

"Build" is currently all the build-scripts/configuration in the gerrit project

"CI" is currently the Jenkins cluster and all ci-scripts[1].

I feel that there's a good argument for keeping them separate.

[1 https://gerrit.googlesource.com/gerrit-ci-scripts/+/refs/heads/master

- Documentation&Homepage into one

I'm not as convinced, to me they are separate.

Documentation - application level

Homepage - community level

- Plugins&Applications&Modules into one: Maybe with some forcing function to set a subcomponent and for the subcomponent to match a repo name?

To me these are also more suitable as separate components. 

+1 Awesome proposition.

[Oswald Buddenhagen]

On Fri, Jun 10, 2022 at 10:34:56AM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>At a later stage we may make setting a component mandatory. All issues
>without a component will be assigned to the 'Backend' component then.
>

it's not reasonable to force the user to make a selection, as they might
not be qualified. it's better to have a fallback component like "Other"
or "General", and also have it be the default selection.

>Proposed components:
>
> - *UX* (replaces 'PolyGerrit>UX', includes any issues with workflows
> not just UI)
>
this kinda makes no sense, as it operates in another dimension than
actual components. in jira, there are the issue types "user story" and
"epic" which can be used to aggregate subtasks, and i suppose monorail
has something roughly equivalent. if the "master" issue extends over
multiple components, it should be assigned to the fallback component.

On Fri, Jun 10, 2022 at 11:20:31AM +0200, 'Ben Rohlfs' via Repo and Gerrit Discussion wrote:
>"Frontend" is a term sometimes used for the web server, as well. So we
>were
>trying to replace "polygerrit" rather with "web" or "web application". But
>I am not sure and don't have a strong opinion on what the best component
>name is here. Maybe "Frontend & WebApplication" or just "WebApplication"?
>

i'd suggest WebFrontend.
this explicitly excludes the ssh interface and the git server, which
wouldn't be intuitively the case for "frontend". i wouldn't use
"application", as it's kinda meaningless - it would fit gerrit as a
whole just as well.

>- Build&CI into one
>
not really. that becomes clearer when you give "CI" a more appropriate
name like "QA Infrastructure", which is clearly distinct from the build
system (that is, the bazel files).

>- Documentation&Homepage into one
>
no; same reasoning as above.

>- Plugins&Applications&Modules into one: Maybe with some forcing function
>to set a subcomponent and for the subcomponent to match a repo name?
>

i suppose that makes sense, as it decouples the logical structure from
the physical repo layout and implementation details, which is
particularly interesting from the user perspective. "AddOns" seems like
a good name for that.

[Edwin Kempin]

On Fri, Jun 10, 2022 at 12:39 PM Oswald Buddenhagen <oswald.bu...@gmx.de> wrote:

On Fri, Jun 10, 2022 at 10:34:56AM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>At a later stage we may make setting a component mandatory. All issues
>without a component will be assigned to the 'Backend' component then.
>
it's not reasonable to force the user to make a selection, as they might
not be qualified. it's better to have a fallback component like "Other"
or "General", and also have it be the default selection.

Yes, if we do this, 'Backend' will be the default component.

The triage process will then change the component if it was wrong.

 

>Proposed components:
>
>   - *UX* (replaces 'PolyGerrit>UX', includes any issues with workflows
>   not just UI)
>
this kinda makes no sense, as it operates in another dimension than
actual components. in jira, there are the issue types "user story" and
"epic" which can be used to aggregate subtasks, and i suppose monorail
has something roughly equivalent. if the "master" issue extends over
multiple components, it should be assigned to the fallback component.

I'm not sure I'm following what user stories and epics have to do with this? I think so far we do not classify issues as such. If we do, I agree that this should not be done via components.

The UX component is intended for issues with user experience in the Gerrit UI or with Gerrit workflows in general.

 

On Fri, Jun 10, 2022 at 11:20:31AM +0200, 'Ben Rohlfs' via Repo and Gerrit Discussion wrote:
>"Frontend" is a term sometimes used for the web server, as well. So we
>were
>trying to replace "polygerrit" rather with "web" or "web application". But
>I am not sure and don't have a strong opinion on what the best component
>name is here. Maybe "Frontend & WebApplication" or just "WebApplication"?
>
i'd suggest WebFrontend.

+1, I like this proposal. Thanks for suggesting it.

 

this explicitly excludes the ssh interface and the git server, which
wouldn't be intuitively the case for "frontend". i wouldn't use
"application", as it's kinda meaningless - it would fit gerrit as a
whole just as well.

>- Build&CI into one
>
not really. that becomes clearer when you give "CI" a more appropriate
name like "QA Infrastructure", which is clearly distinct from the build
system (that is, the bazel files).

>- Documentation&Homepage into one
>
no; same reasoning as above.

>- Plugins&Applications&Modules into one: Maybe with some forcing function
>to set a subcomponent and for the subcomponent to match a repo name?
>
i suppose that makes sense, as it decouples the logical structure from
the physical repo layout and implementation details, which is
particularly interesting from the user perspective. "AddOns" seems like
a good name for that.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/YqMfRn4mFtoWGMsF%40ugly.

[Oswald Buddenhagen]

On Fri, Jun 10, 2022 at 12:55:55PM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>On Fri, Jun 10, 2022 at 12:39 PM Oswald Buddenhagen <oswald.bu...@gmx.de> wrote:
>> On Fri, Jun 10, 2022 at 10:34:56AM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>> >At a later stage we may make setting a component mandatory. All issues
>> >without a component will be assigned to the 'Backend' component then.
>> >
>> it's not reasonable to force the user to make a selection, as they might
>> not be qualified. it's better to have a fallback component like "Other"
>> or "General", and also have it be the default selection.
>>
>Yes, if we do this, 'Backend' will be the default component.
>The triage process will then change the component if it was wrong.
>

the result of that is that some users assign issues to more or less
random components. and given that some components are "not quite as well
triaged", that just increases the overall noise in the system.

>The *UX* component is intended for issues with user experience in the

>Gerrit UI or with Gerrit workflows in general.
>

yes, and my point is that UX isn't a component, but a property of
(possibly multiple) components. having such a "fake" component just
creates a mess. use a hotlist/label/whatever instead, which is
specifically designed to create separate categorization axes.

also, maybe spell out UserExperience?

[Edwin Kempin]

On Fri, Jun 10, 2022 at 4:28 PM Oswald Buddenhagen <oswald.bu...@gmx.de> wrote:

On Fri, Jun 10, 2022 at 12:55:55PM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>On Fri, Jun 10, 2022 at 12:39 PM Oswald Buddenhagen <oswald.bu...@gmx.de> wrote:
>> On Fri, Jun 10, 2022 at 10:34:56AM +0200, 'Edwin Kempin' via Repo and Gerrit Discussion wrote:
>> >At a later stage we may make setting a component mandatory. All issues
>> >without a component will be assigned to the 'Backend' component then.
>> >
>> it's not reasonable to force the user to make a selection, as they might
>> not be qualified. it's better to have a fallback component like "Other"
>> or "General", and also have it be the default selection.
>>
>Yes, if we do this, 'Backend' will be the default component.
>The triage process will then change the component if it was wrong.
>
the result of that is that some users assign issues to more or less
random components. and given that some components are "not quite as well
triaged", that just increases the overall noise in the system.

OK, what's your proposal then?

 

>The *UX* component is intended for issues with user experience in the
>Gerrit UI or with Gerrit workflows in general.
>
yes, and my point is that UX isn't a component, but a property of
(possibly multiple) components. having such a "fake" component just
creates a mess. use a hotlist/label/whatever instead, which is
specifically designed to create separate categorization axes.

I see, thanks for explaining. I agree that we should consider using a hotlist instead of having this component.

This will impact the current process of how issues are assigned between the frontend and UX teams,

so I would like to discuss this with them before we make this change. I suggest that we do this after the

general cleanup of the components and keep UX as a subcomponent of the Frontend component (or whatever

name we choose here) for the first iteration (basically leave this for the first iteration as it is now).

 

also, maybe spell out UserExperience?

I would be fine with this too, and actually we considered this. But I think UX is used much more frequently than

the spelled out UserExperience, hence I thought UX would be more recognizable by users and hence I thought

it's better to keep this component, or now hotlist, as UX. What do others prefer?

 

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/YqNU9gCgLQriJCQt%40ugly.

[Edwin Kempin]

Thanks a lot for all your feedback. Much appreciated.

We have discussed this in the last community manager meeting and want to proceed like this:
* Follow the initial proposal with the following changes:

   1. Use a hotlist for UX rather than a component

   2. Use a more specific name for the Frontend component, we've chosen WebFrontend now. 

Edwin on behalf of the community managers

[Sven Selberg]

On Wednesday, June 29, 2022 at 5:07:57 PM UTC+2 Edwin Kempin wrote:

Thanks a lot for all your feedback. Much appreciated.

We have discussed this in the last community manager meeting and want to proceed like this:
* Follow the initial proposal with the following changes:

   1. Use a hotlist for UX rather than a component

   2. Use a more specific name for the Frontend component, we've chosen WebFrontend now. 

Edwin on behalf of the community managers

Thanks Edwin, Nasser and Matthias for this much needed improvement!

[Edwin Kempin]

Just to let you know, I started with cleaning up the components in Monorail now.

Most components have already been changed as discussed, only some still need to be done (TODO: PolyGerrit -> WebFrontend, PolyGerrit>UX -> UX hotlist, googlesource -> googlesource hotlist).

I will probably continue with this only next week.

If you use any queries for Gerrit issues, please adapt them to the new components.

[Luca Milanesio]

On 6 Jul 2022, at 14:17, 'Edwin Kempin' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Just to let you know, I started with cleaning up the components in Monorail now.

Most components have already been changed as discussed, only some still need to be done (TODO: PolyGerrit -> WebFrontend, PolyGerrit>UX -> UX hotlist, googlesource -> googlesource hotlist).

I will probably continue with this only next week.

Cool stuff, thanks again Edwin !

Luca.

To view this discussion on the web visit https://groups.google.com/d/msgid/repo-discuss/147ddc7e-6881-4986-ade0-ddcf31779ed6n%40googlegroups.com.

[Edwin Kempin]

On Wednesday, July 6, 2022 at 10:04:43 PM UTC+2 lucamilanesio wrote:

On 6 Jul 2022, at 14:17, 'Edwin Kempin' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

Just to let you know, I started with cleaning up the components in Monorail now.

Most components have already been changed as discussed, only some still need to be done (TODO: PolyGerrit -> WebFrontend, PolyGerrit>UX -> UX hotlist, googlesource -> googlesource hotlist).

I will probably continue with this only next week.

The component cleanup is fully done now.

The googlesource component was moved to Hosting>googlesource. It turned out that this component was not used by the Gerrit backend team at Google for triaging (triaging already used the Host-Googlesource hotlist/label), but it's for specific issues with googlesource Gerrit installations, e.g. to request configuration changes, to request banning spamming users etc., and we actually need to keep a component for these purposes.