Github: New style Projects

[Jay-o-Way]

We should use the new version of "Projects".
https://docs.github.com/issues/planning-and-tracking-with-projects/creating-projects/migrating-from-projects-classic

Also handy: https://github.com/orgs/github/projects/4247/views/1?filterQuery=-status%3A%22Q4+2021+%E2%80%93+Oct-Dec%22%2C%22Q1+2022+%E2%80%93+Jan-Mar%22+Projects

YouTube:
https://youtu.be/MYNIXz9iViU (10 min.)
https://youtu.be/UTDAlZFhPyM (4 short videos)

Personally, I would make one for each module. More specific: Large issues (read: projects) that are on the backseat but definitely need attention:

• Investigate scancodes / vKey [Clint] 14055 ↔ KBM UI 2027
• Quick Access fly-out 6751
• Shortcut Guide v2 890
• Image Resizer UI update 1053
• VCM toolbar 15866 / 21473
• PowerRename UI update 888

No projects for:

• "idea-new-powertoy" → use a bucket/milestone
• "localization" → is a property

We currently have 121 labels (!) After using projects, we need a lot less labels, so we can clean them up!

Projects (products/toys) (~26 labels)

• "tracker", "ui refresh" 🗑
• Settings, “top-level” modules (18 existing), runner, installer (~21)
• Online (GitHub, MS docs, MS store)
• build

Fields (status/properties) (24~34 labels)

• status [Blocked, NeedsRepro, NeedsValidation, Reproducible, WaitingForInput, ToDo, InProgress, Done, Stale] (≥9)
• cost [small, medium, large] (3)
• priority [low, med, high, blocking, HotFix] (5)
• area-xxx [UI, localization, tests, quality, accessibility, telemetry, etc.] (~7?)
• for selected toys/projects: "sub-module"; examples:
  • Mouse Utils > FMM + highlight + crosshairs
  • File Explorer > Thumbnail + Preview Pane
  • FancyZones > Editor
  • Web > GitHub, MS Docs Learn, MS Store

Resolution-xxx (10) doesn't need to be a field, because you can't apply a field if an issue is not linked to a project.

(I have many, many more ideas regarding labels, but that can be addressed in a different issue.)

Questions

• I like to use emoji, is that alright?
• Is ~20 Projects a lot? Consider the 3.8k of open issues we have, we can spread them to make the Projects themselfs more managable.
• Should we focus on putting issues, prs or both in Projects?

---

Made a personal repo

https://github.com/Jay-o-Way/Learning-this

Have a look at my Discussions, Milestones and Projects!

Project:

Properties/fields when viewing an issue:

[Aaron-Junker]

@crutkas answer from #16565:

I'm going to close this out as ultimately, this will be the plan but as of now, they are not in a state where we can. Chances are when terminal does, we will as well.

we'll revisit in a few months but right now, just some big deal breakers for speed of triage.

[Jay-o-Way]

Okay I see. But it is a few months later now. And I don't have any experience of working with Projects, so I don't know (yet) how that influences triage..

[crutkas]

Triages goal is to get clarity, see if we can reproduce the bug (if it is one), dedup and be sure we understand what is being asked.

Just because it is there now doesn’t mean we need to instantly use it. I’ll try it again soon

[Jay-o-Way]

[Aaron-Junker]

@Jay-o-Way you have to click on the repository tab to see the projects

[Jay-o-Way]

@Aaron-Junker you mean this one?

(I think) They're empty because the now "normal" Projects are not used.

[Aaron-Junker]

Weird. I have no problem with it

[Jay-o-Way]

Oh in that case it must be a matter of access/rights I guess

[Aaron-Junker]

Some concepts how it could be configured:

--

--

--

--

--

--

--

--

--

[crutkas]

I need to see how this works now vs before. The issue was linking stuff was tied to the organization aka Microsoft. Trying to quick assign stuff was … interesting

with that said, been a while. Right now this is not a pressing issue IMO unless I’m missing something