After some more discussion, here's another concrete proposal...
Issue types: ------------ (go from top to bottom when deciding which to use) Patch = A concrete code change that should be discussed/reviewed/tested Unimplemented = Windows has this, we don't Bug = Something is broken and should be fixed Improvement = Something exists/works but can be made better, given more features etc. Task = Any work to be done that doesn't fit in the above
Components: ----------- audio applications build system [cmake files, host tools] crt [crt, msvcrt*, stlport, ...] 3dgraphics [directx, mesa/gallium] drivers filesystems [can maybe go into drivers] freeldr include [? ddk, ndk, xdk, psdk; not sure if needed] networking [winsock, afd, ndis, dhcp, ...] ntcore [rtl, ntdll, ntoskrnl, hal] plugandplay [umpnpmgr, setupapi, newdev] security [? lsa*, sam*, secur*] services [services.exe, svchost, rpcss, spoolsv, ...] shell [cmd, explorer, shell32, browseui, ...] translation uniata usb win32ss [win32k, user32, gdi32, csrss, ...] wine [libwine, dlls] rosdlls [advapi32, kernel32, vdmdbg, userenv]
(note that "module" is in planning as a separate field)
The uniata and translation components are mostly motivated by "default assignee" thinking; so if that can be done manually or independently, that should be reconsidered.
I think this layout would make a good mapping to "what areas are you interested in". E.g. a kernel dev could choose ntcore, drivers, filesystems to get a good default filter.