improvements to the triaging process

Would be nice to have a new type::device-port label too.

By f_ on 2024-03-09T15:47:01

I think we have a lot of labels with questionable degrees of usefulness as well. "status::duplicate", ironically, duplicates a built-in GitLab feature. "type::fix" and "type::feature" are seldom useful in pmaports, at least, as merge requests often can bring in both features and fixes, and in those cases it's not clear which one should choose. Additionally, when do you want to sort MRs after whether they introduce features or fix bugs anyway? The whole "category"-class of labels I'm not sure how useful they ever are either.

By Newbyte on 2024-03-10T13:32:28

Thanks a lot for the suggestion!

I'd be fine with adding more labels, and adding ones for the subsystems seems useful at first glance - it would be rather intuitive to add them, and people could subscribe to individual subsystems (I'm not sure if anybody is doing that though).

Maybe that is something we should figure out first: would people actually subscribe to subsystem labels? or what would the purpose be? Depending on that, we can figure out if it is worth adding more labels or not.

Agreed with Newbyte, some of the labels we have right now need to be reworked (and maybe the whole triaging workflow?) - unfortunately it seems a bit like we have a lot of labels, but it is not intuitive when they should be applied and so it is done inconsistently.

"status::duplicate", ironically, duplicates a built-in GitLab feature. "type::fix" and "type::feature" are seldom useful in pmaports, at least, as merge requests often can bring in both features and fixes, and in those cases it's not clear which one should choose. Additionally, when do you want to sort MRs after whether they introduce features or fix bugs anyway?

agreed, I'd be fine with removing status::duplicate, type::fix and type::feature

The whole "category"-class of labels I'm not sure how useful they ever are either.

In theory it should help with immediately seeing how much an issue impacts users, i.e. issues affecting main and community devices are more important than devices that "only" affect devices in the testing category. But then again, it is extra effort to apply these labels and FWIW personally I don't think I found myself paying that much attention to the device category labels. Also if a device gets moved in categories, we would need to adjust the labels as well if we did it properly... Maybe we should remove them as well?

I wouldn't mind if we ended up only having very few labels, which are used consistently throughout the bug tracker and where it would be very clear on how to use them.

I guess ideally somebody could go through each label, existing or newly proposed, and write down:

what the purpose of the label is
if it really fulfills the purpose
if the name of the label is intuitive or not
make a recommendation (keep/remove/discuss further)

By Oliver Smith on 2024-03-10T13:47:56

Thanks a lot for opening this issue, but seems like you opened a bit can of worms

I think the labels you propose could be useful. But I think the biggest problem I have with the issue tracker is how hard it is to find things that I actually care about (partially my fault, I just subscribed to the ui labels...). I have the feeling that most issues are actually random device issues and support problems, that few people care about. And I really don't know how to do it to improve this process, it just takes sooo long to ask people for reproducers, etc.

By Pablo Correa Gomez on 2024-03-14T23:20:55

Some recent community device labels are still not added yet. I tried to add device-samsung-expresso7,device-samsung-expresso10, etc.

By Raymond Hackley on 2024-03-16T08:53:16

Quick update:

Had a look at the list of labels on the org-page in GH.

Priotized labels:

Name	Comment
security	keep
typebug	remove as we have refinded status in the other labels below

Other labels

For Action: k - keep, r - rename, d - depreciate

Name	Action	Comment/idea
SDM845	r	rename to `soc-SDM845`
Waydroid	r	appl-Waydroid
a11y	k
android-recovery-zip	k
backport-to-v21.03	k
backport-to-v21.06	k
backport-to-v21.12	k
backport-to-v22.06	k
backport-to-v22.12	k
backport-to-v23.06	k
backport-to-v23.12	k
categorycrossdirect	k
categorydevice	d	use/create the applicable device- label
categoryinfrastructure	k
categoryui	k
categoryupgrade	k
chromeos	r	create a meta-label like `device-chromebooks`
ci	k
device-arrow-db410c	k
device-asus-me176c	k
device-bq-paella	k
device-categorycommunity	k
device-categorymain	k
device-categorytesting	k
device-fairphone-fp4	k
device-generic-x86_64	k
device-lenovo-21bx	k
device-lenovo-a6000	k
device-lg-hammerhead	k
device-motorola-harpia	k
device-nokia-n900	k
device-nvidia-tegra-armv7	k
device-odroid-hc2	k
device-oneplus-enchilada	k
device-oneplus-fajita	k
device-pine64-pinebookpro	k
device-pine64-pinephone	k
device-pine64-pinephonepro	k
device-pine64-pinetab	k
device-pine64-rockpro64	k
device-purism-librem5	k
device-qemu-aarch64	k
device-qemu-amd64	k
device-samsung-a3	k
device-samsung-a5	k
device-samsung-e7	k
device-samsung-espresso10	k
device-samsung-espresso7	k
device-samsung-grandmax	k
device-samsung-m0	k
device-samsung-manta	k
device-samsung-serranove	k
device-shift-axolotl	k
device-valve-jupiter	k
device-wileyfox-crackling	k
device-xiaomi-beryllium	k
device-xiaomi-daisy	k
device-xiaomi-mido	k
device-xiaomi-scorpio	k
device-xiaomi-wt88047	k
difficultycomplex	k
difficultyeasy	k
discussion	k
documentation	k
hacktoberfest-accepted	k
help wanted	k
initramfs	k
porting	k
release-edge	k
release-v20.05	k
release-v21.03	k
release-v21.06	k
release-v21.12	k
release-v22.06	k
release-v22.12	k
release-v23.06	k
release-v23.12	k
request-for-test	k
service-pack-discussion	k
status:mr-stale	d	to be discussed, do we want to audo-close-mr after X month of not resolving the open threads
statusconfirmed	k
statusduplicate	d	link the initial issue?
statusfixed	d	issue closed or MR will be completed
statusinvalid	k
statusneedmoreinfo	k
statusnotourbug	k
statusreported	d	to be discussed
statuswontfix	k
technical debt	k
typefeature	k
typefix	k
typesupport	k
typetask	k
ui-asteroid	k
ui-console	k
ui-fbkeyboard	k
ui-framebufferphone	d	to be discussed
ui-glacier	d	to be discussed, is glacier still in use?
ui-gnome	k
ui-gnome-mobile	k
ui-i3wm	k
ui-kodi	k
ui-lomiri	k
ui-lxqt	k
ui-mate	k
ui-phosh	k
ui-plasma-bigscreen	k
ui-plasma-desktop	k
ui-plasma-mobile	k
ui-shelli	k
ui-sway	k
ui-sxmo	k
ui-weston	k
ui-xfce4	k

new label ideas:

Name	Comment
soc-*	for SoC-families, like `soc-SDM845`, `soc-exynos4`
auido	generic for audio related topics
audio-alsa	for ALSA and UCM related
audio-pulse	for PulseAudio
audio-pipe	for pipewire
network-lan	Ethernet and Wifi
network-wwan	mobile data
mainlining

Please keep your ideas and opinions coming!

I still planning to do a more detaille drill down on the usage of labels, hover have not come far due to missing time in the last weeks

By Robert Eckelmann on 2024-03-16T13:17:12

Spend some time thinking about some basic categories and items.

PMOS project labels

security
breaks-edge
CoreTeam
TrustedCntributors
TestingTeam
Infrastructure

Status and classification:

type:bug
type:fix
type:feature
type:support
needs_more_input
technical_debt
discussion
help_wanted
tests_needed
ci

**pmaports specific labels **

Status (pmaports specific):

release-{v22.06, v25.04, edge,..}
back-port
service-pack

Device & SOC related:

device-{manufacturer]-[codename] ---> as before, including generic packages, like nvidia-tegra-armv7)
soc-generic-package ---> for the creation of generic packages
soc-{SDM845, SM6350, tegra,...} ---> for SoC topics, which are not covered by the generic devices
device-category:community
device-category:main
device-category:testing
device-category:archived (?)
category-upgrade
category-downgrade

boot related:

boot:u-boot
boot:lk2nd
boot:systemd-boot
boot:uefi
initramfs
FDE

firmware & kernel related:

firmware-FOSS
firmware-(nonfree)
kernel-mainline
kernel-downstream
kernel-config
kernel-config-fragments
...

networking:

network:wlan
network:bt
network:mobile-data-and-voice
network:VoLTE
network:usb-ethernet
network:usb-tethering
network:wpa_supplicant
network:iwd

graphics & input:

3d_accel
framebuffer
mesa
touchscreen
external_input_devices
camera

userland & UI:

UI:{xfce, mate, phosh, gnome-mbile... as before}
audio
audio:alsa
audio:pulse
audio:pipewire
flatpak
pmos_contrib
a11y

Comments are welocme

By Robert Eckelmann on 2024-04-30T21:44:09

Spent some time these last couple of days digging around in issue (and making a little noise as I got confused what project issues are in, like the webflash one, so sorry about that!). This started from discussions Caleb, Clayton, and I had these last weeks about how to triage issues for the systemd work. I wanted to get the ball rolling there, so I updated the triaging page with a few additional categories. I also updated all the ui and device labels in pmaports to be scoped properly, but didn't go beyond that even though there are others (backport, release, etc.) that look like they could use it.

Reading through this issue, labels are really about coordination, as in a process. Making sure the right people see the right issues and that everyone also knows their status. I think there's a ton of dimensionality as we can see. But I'm wondering what we actually do with this information?

I think there are 3 dimensions: user impact, who cares to fix it, and what's the status:

user impact: device, soc, ui, release labels seem relevant here.
who cares to fix it: basically follows from the above. But should people be pulled in (I think this is common with device-specific issues). What about the others? Are maintainers listed for everything? Kind of brings up the concept of subteams. a11y has had folks specifically interested in it.
status: these seem well defined (well, tracking if it's an upstream issue seems a bit more nebulous)

By Bryant Mairs on 2024-05-12T09:02:24

BTW is https://wiki.postmarketos.org/wiki/Triaging supposed to be unlocked? Saw it's in the Admin section of the wiki, where most pages are locked (though Creating a release branch, and creating a service pack aren't either). Happy to open a new wiki issue to track this if it should be looked at.

By Bryant Mairs on 2024-05-15T11:14:40

Probably should be locked yes Feel free to ask Luca, whose the wiki master

By Pablo Correa Gomez on 2024-05-15T11:14:40

Some other aspects of this:

Should upstreaming be tracked (I think that's all https://gitlab.com/postmarketOS/pmaports/-/issues/47 is doing)? We have some tags already around this, but they're not very clear.
How does this work with the larger community? help wanted/request-for-test + difficulty tags seem useful for that. Could also promote them more widely (TWiR highlights some from various crates in their weekly blogpost that I think is really cool).
How do we link this all together so people can figure it out? I just scoped all the ui labels and found that some are missing wiki pages (GNOME mobile, console, fbkeyboard, framebufferphone, kodi). Having a wiki page for things I'd think is high value to get this useful to the wider community as well.

By Bryant Mairs on 2024-05-12T09:10:21

How does this work with the larger community? help wanted/request-for-test + difficulty tags seem useful for that. Could also promote them more widely (TWiR highlights some from various crates in their weekly blogpost that I think is really cool).

We could have such topics also mentioned at the end of blog-posts or in the podcast.

By Robert Eckelmann on 2024-05-12T12:02:13

https://blogs.gnome.org/aday/2024/05/17/gnome-maintainers-heres-how-to-keep-your-issue-tracker-in-good-shape/ talks a bit about the GNOME approach. They highlight a key point: keeping the issue queue as a list of things worth doing, not a database of every idea or bug. So they have timelines to close issues that don't get worked on.

I think that's a pretty interesting idea and one that will likely dictate much of the process. I was looking through the oldest issues and there are 5yo issues. Not certain if having those around is useful.

I think having timelines for issues and MRs to stay open in different contexts could make a lot of sense.

By Bryant Mairs on 2024-05-17T16:28:58

While I don't necessarily think we need to go that far, I think we at least should disallow creating issues about ideas you have no plans to implement. I've been guilty of this myself in the past, but it's something I think clogs the issue tracker with things that just aren't useful.

The reason I'm not sure about whether to go that far is because searching the issue tracker for issues about a particular device can be useful for gauging whether this device has any particular things that would prevent it from being useful for your needs before buying it. This is unlike GNOME where you just can install a program and try it out and uninstall it if you don't like it. I don't think tracking issues on the wiki is a better paradigm.

By Newbyte on 2024-05-17T16:28:58

@longnoserob I see quite some of these labels were added, and you updated https://wiki.postmarketos.org/wiki/Triaging super nicely. Can we close this?

Yes lets close this!

closed

improvements to the triaging process

Child items ...

Activity