revisiting the "easy pickings" flag in Trac

[Tim Graham]

In my experience the "easy pickings" flag is ill-defined and insufficient for describing the difficulty of a ticket. I don't want to get stuck in categorizing tickets just for the sake of it, but I think a drop down with options like the following could be useful in helping contributors find suitable tickets:

Trivial - Typos, wording tweaks, etc.
Easy - Simple features and bugs suitable for a first-time contributor.
Moderate - Requires a basic knowledge of Django internals.
Hard - Requires a thorough understanding of Django internals.
Very Hard - Refactorings or features that are difficult for experienced core developers.

Do you think this would be useful? If so, are the selections above suitable?

[Michael Manfre]

I never liked the "easy pickings" flag either. Your proposed change would be a good way to identify the technical ability required to make the changes to Django. Should we have a separate drop down with options to identify the non-technical (bikeshedding) difficulty of the ticket? There are certain tickets that are created that are not immediately closed as won't fix that are not a technically challenging problem, but are a huge uphill battle to get merged.

  

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5544efa8-75a0-40ba-9210-bea027d32a72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

GPG Fingerprint: 74DE D158 BAD0 EDF8

keybase.io/manfre

[Russell Keith-Magee]

My concern would be bike shedding of the difficulty. Unless the type of change is completely objective (e.g., it's a typo vs a code/logic change) your "easy" may be my "hard", or vice versa. 

Even the "is it a bug or a feature" distinction has historically caused problems. If the test client doesn't support a particular HTTP verb, is that a bug (because it's not fully HTTP compliant), or a missing feature (because we didn't say it was fully HTTP compliant)?

To my eyes, the purpose of "easy pickings" was to be a semi-curated list of stuff that we could throw at someone who says "I want to contribute - what should I work on?". 

However, even that is a fuzzy target - a ticket may be marked "easy pickings" because it points out a trivial misinterpretation of the HTTP spec - but if you don't know the HTTP spec really well, that means you have to read the RFC before you can contribute.

Part of the task of skilling someone past the "first contribution" point is teaching them how to identify the next problem to solve.

Overall - I'm not convinced that adding more detail to this category will be helpful.

Yours,

Russ Magee %-)