[Cc list redux] Astron wrote:
I'll try to produce something in the next few days.
Thanks a lot for that!
And about all the politics here ... I just don't know where to stand. The two Easy Bugs in question here really seem to have been easy hacks, so at least superficially the description fit. About the notion that there should always be a dev to mentor people on Easy Hacks, I don't know... the term "Easy Hack" doesn't really fit then, "Mentoring bug" might be more appropriate here (but I agree that outsiders – like myself – can't actually judge how hard certain code is to change). The most important thing is probably that TDF has a good and consistent definition of the term Easy Hack, and following that, a section about filing (proposed) Easy Hacks) should be added to the EH wiki page.
The very category EasyHack (as cloph pointed out) needs dev insight to tag a bug with - simply because simple, innocent-looking changes may be two week's worth of effort. The category Chris was referring to were "UX Easy Hacks", or maybe "paper cuts" is a better term - tiny, but annoying quirks in the UI, that have some probability of not needing too much coding work (therefore providing a nice source of potential future EasyHacks - devs can, while waiting for a compilation to finish, idly check them).
What might be a good idea would be to have a script run once a day that checks which bugs have been newly marked with "EasyHack" and then have someone sort through the results (this would probably need work from developer and also a designer/UX'er).
Bit above my understanding of bugzilla's monitoring capabilities - not sure how much strain to fdo's servers a daily XMLRPC query over all bugs would be - that set aside, a useful thing to have for sure. Maybe something you'd like to look into after doing the pdf UI changes? Cheers, -- Thorsten
Attachment:
pgpxFHkIw9rn0.pgp
Description: PGP signature