[core-workflow] Adding a "requires C" keyword?

[Nick Coghlan]

On 4 Aug 2014 09:37, "Ezio Melotti" <ezio.melotti at gmail.com> wrote:
>
> Hi,
>
> On Sun, Aug 3, 2014 at 4:23 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > Chatting to an experienced C/C++ developer at PyCon AU today, they
> > were worried that their *Python* skills might not be good enough to
> > contribute to CPython. It reminded me of an idea I had a while ago,
> > but forgot to suggest: adding a keyword specifically to indicate
> > issues that require some C coding.
> >
> > My main rationale is that there are some issues that are likely to be
> > pretty easy *if you already know C*. Adding the extra keyword means we
> > can mark:
> >
> > - easy Python only issues (just the 'easy' keyword)
> > - easy C or C+Python issues ('easy' and 'requires C' keywords)
> > - tricky Python only issues (no keywords)
> > - trick C or C+Python issues (just the 'requires C' keyword)
> >
> > I'm not particularly enamoured of that specific keyword name, so I'm
> > interested in two specific kinds of feedback:
> >
> > 1. Does the extra keyword sound useful?
>
> The request seems reasonable to me, even though any keyword we add
> makes the triaging (slighly) more complex and this causes several
> problems (more difficult to see/set keywords without scrolling through
> a longish list, increasing the chances that users will ignore the
> field if it looks too complicated, etc.)
>
> Note that it should be already possible to identify most of the C
> issues by looking at issues with components "Interpreter core" and
> "Extension Modules".  This could become a new query.
>
> In addition to C and Python, we also have rst that is also
> indicated/implied by the "Documentation" and "Devguide" components.
> Throwing rst in the mix makes things even more complicated though, and
> a new "languages" field would add more problems than it would solve.
>
> Considering more effective ways to find/filter issues might also be
> more effective than adding additional metadata.

Ah, I like the idea of being more explicit about mapping components to a
primary language, and then providing "Mostly C", Mostly Python" and "Mostly
ReST" searches.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20140804/257c43be/attachment.html>