PR and Issue triage ?

[JimFuller-RedHat]

Would anyone be interested in doing a group scrub on the PR/issues ? If so I can set something up.

[pombredanne]

@JimFuller-RedHat awesome idea and your help is much welcomed! What shape you think this would take?

[johnmhoran]

@JimFuller-RedHat I agree with @pombredanne -- this would be awesome.

FYI, I've been working on vetting, organizing and beginning to analyze the roughly 100 open issues and 50 open PRs, and have created a Google Sheet in which I'm tracking these issues/PRs. https://docs.google.com/spreadsheets/d/1H2QAcADLaMNgcR5BMK7bQxzH5D3X-SdO

We've also tagged the issues/PRs with a number of existing and new labels and are currently focusing on those tagged Ecma specification, meant to ID the core spec work. As a subset of those, I've created a second Google Sheet focused primarily on the 12 issues/PRs that involve encoding. https://docs.google.com/spreadsheets/d/1biOCUY4eCqQaYmfGDHVrASV9igYEzct6 I've added relevant data etc. for 3 of the 12 tagged PURL encoding and tomorrow will resume doing the same for the remaining 9.

Perhaps one or both of these could be useful in the group scrub you proposed above. I look forward to your thoughts on the group scrub and more broadly as well.

[JimFuller-RedHat]

I was thinking to schedule a triage meeting and use your spreadsheets as source to go through and see if we can route/close issues or PRs .... please suggest whom should be invited (I might try to cajole a few Red Hat prodsec people as well).

[johnmhoran]

Thank you @JimFuller-RedHat . If you could change the time of your triage meeting to 8:00 AM or 9:00 AM Pacific (I'm in California), I would love to join (earlier is a bit difficult for my internal clock ;-).

As for other invitees, some of the more active community members atm include @pombredanne , @stevespringett , @jkowalleck and @sschuberth , and I'm sure there are others I'm missing. (Activity in the issues/PRs tagged with the Ecma specification label would be one relevant indicator.)

[johnmhoran]

Thank you @JimFuller-RedHat . 👍

[jkowalleck]

i can not participate in any meetings before 2025-01-07. Please remind/ping me again early next year :-D

[johnmhoran]

@JimFuller-RedHat A slight schedule update -- I spoke with @pombredanne and these proposed dates/times would work for us both (in CET rather than GMT+1 ;-):

Wednesday Dec. 18 at 18:00 CET / 9:00 PST
Thursday Dec. 19 at 18:00 CET / 9:00 PST
Friday Dec. 20 at 17:00 CET / 8:00 PST

Would any of these fit your and your colleagues' schedules?

[JimFuller-RedHat]

pURL triage
Wednesday, December 18 · 6:00 – 6:45pm CET / 9:00 PST
Time zone: Europe/Prague
Google Meet joining info
Video call link: https://meet.google.com/pdm-ukze-pbm
Or dial: ‪(CZ) +420 234 610 848‬ PIN: ‪538 413 427‬#
More phone numbers: https://tel.meet/pdm-ukze-pbm?pin=1310670270923
Or join via SIP: sip:[email protected]

chat: https://app.gitter.im/#/room/#package-url_Lobby:gitter.im

If anyone want an invite for their calendars just send an email to me ([email protected]).

Agenda

• (short) Introductions
• Review of PR/Issues

Look forward to meeting everyone!

[pombredanne]

Awesome! I will be there

[pombredanne]

And I will @ ping a few folks nicks that showed interest in other issues

[johnmhoran]

Thank you @JimFuller-RedHat -- I look forward to the triage meeting.

As I mentioned a few days ago, I'm using a Google Sheet to identify and work with the full set of open issues and PRs in the purl-spec repo. https://docs.google.com/spreadsheets/d/1H2QAcADLaMNgcR5BMK7bQxzH5D3X-SdO Some of the column data has been overtaken by changes, but I'm trying to keep the information in columns A-F and I (Priority, Title, Ecma spec, PO input, status, Feedback and Links) current.

• The two key sheets are the 'issues' and 'pull_requests' sheets.
• The core spec issues/PRs are indicated by a 'yes' in the 'Ecma spec' column (col. C).
• @pombredanne has suggested we include golang-related issues and PRs as well in the core spec focus. Note that only 2 of the 9 golang-related are also tagged 'yes' in the 'Ecma spec' column (based on the labels added in GitHub).

In terms of what is and is not yet being addressed for the core spec focus,

• I'm currently working on a group of encoding-related issues/PRs in a separate gSheet. https://docs.google.com/spreadsheets/d/1biOCUY4eCqQaYmfGDHVrASV9igYEzct6
• The golang-related issues/PRs have not yet been addressed, nor have the other issues/PRs that have 'yes' for 'Ecma spec' and are not encoding related or otherwise included in the encoding gSheet.

I'm available to answer any questions you or others have about this rather large collection of issues, PRs and related data.

[JimFuller-RedHat]

Great !

From those docs - there seems to be a few 'buckets' of activity which I will over simplify as:

• Core spec errata/new
• Package type errata/new
• ECMA related requirements
• Docs
• Test
• Version ranges errata/new

I can imagine wrangling all these might be a challenge ... could be worth putting willing people's names against each to facilitate async work & alignment - subdividing the work. For those long on the project, it might be apparent who the right person is - though as much of the lore of the project is baked
in issues/prs/etc ... perhaps we try, during triage, to create a CONTRIB.md doc with this kind of info ?

For me a successful triage meeting would:

• Close as many issues/PR that are stale, not relevant, etc ... this reduces cognitive load and if things are truly important issues can always be re-opened (we could consider have a standard boilerplate like 'Issue closed - but can be re-opened' type approach ?
• Address issues/PR that are 'low hanging fruit' ... by motivating someone to get through the 'last mile' (or just a simple response on the issue/PR itself)
• Discuss 1-2 highest priority issues/PR to move it along - this implies relevant people should be in participation in the meeting to be able to have the discussion
• Spawn async design meetings (avoid deep dives, keep things moving)
• Have Meeting minutes recorded outlining decisions taken and actions committed

If @pombredanne / @johnmhoran could identify some candidates for discussion, before triage even better ;)

There is no way (without declaring some 'bankruptcy') that we can be comprehensive in a single meeting - also (as with all spec efforts) there are competing forces for time/attention/priority - for example - getting a new type added versus addressing some tedious errata in the spec ... we can try to identify willing people to work on what they are interested in. If we find this triage useful we can schedule another one.

Lastly - I do not want to step on anyone's 'toes' (or run over already important onging work like ECMA) ... my personal goal is to try and help the project along and get the spec on firmer footing.

[johnmhoran]

@JimFuller-RedHat Here are a few thoughts re how people could vet the current set of open issues/PRs and identify those individual or groups of issues/PRs to address.

• People might want to consider looking at the full set of GH labels (currently 94 -- https://github.com/package-url/purl-spec/labels) and exploring those that look interesting.

• One suggested focus is what has been our highest priority -- the Ecma specification label (link) -- 60 open issues/PRs as of 2024-12-15.

  • Note that there are 16 open issues/PRs labeled PURL core specification (link) -- all are also labeled Ecma specification
  • PURL encoding label (link) -- 15 (all are also labeled Ecma specification) -- I am currently organizing and analyzing, planning to tackle each component and PURL location (e.g., between components) one-by-one.
  • type: golang label (link) -- 8 (only 2 of which are also labeled Ecma specification)
  • Aside from 15 labeled PURL encoding (all are also Ecma specification) and 8 labeled type: golang (2 are also Ecma specification) -- that leaves 43 labeled Ecma specification to address.

• Proposed new type label (link) -- 47

• There are also labels for each of the PURL components [JMH edit: no label yet created/needed for PURL type component -- created and added link below] -- note that while the number of issues/PRs with these labels might be relatively high, some will also be focused on a single existing or proposed type (and thus might not easily lend themselves to addressing as a group).

  • PURL scheme component (link)
  • PURL type component (link)
  • PURL namespace component (link)
  • PURL name component (link)
  • PURL version component (link)
  • PURL qualifiers component (link)
  • PURL subpath component (link)

[jkowalleck]

re: #360 (reply in thread)
I took the liberty to edit your comment and I've added a link for every mentioned label in your comment above, @JimFuller-RedHat . This way,it is easier to follow up.
Unfortunately, I was unable to find that label PURL type component. could you check and maybe fix or link the correct label for this one?

[johnmhoran]

@jkowalleck Thank you for adding the individual label links -- good idea. I've created a label for PURL type component.