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

[Nick Coghlan]

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?
2. Any other suggestions for a name?

Cheers,
Nick.

[francis]

Hi Nick,

Post by Nick Coghlan
I'm not particularly enamoured of that specific keyword name, so I'm
1. Does the extra keyword sound useful?

Yes, IMHO it's useful



Just complementary info about the context where the new keyword should
be used is [1] (AFAIK):


buildbot
A buildbot triggered the issue being reported.

easy
Fixing the issue should not take longer than a day for someone new
to contributing to Python to solve.

gsoc
The issue would fit as, or is related to, a GSoC project.

needs review
The patch attached to the issue is in need of a review.

patch
There is a patch attached to the issue.

3.3regression
The issue is a regression in 3.3.



----
[1] https://docs.python.org/devguide/triaging.html


Regards,
francis

[Mark Lawrence]

Post by Nick Coghlan
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
- 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
1. Does the extra keyword sound useful?
2. Any other suggestions for a name?
Cheers,
Nick.

+1 as a complete no brainer from my viewpoint. As an example wouldn't
it help here http://bugs.python.org/issue13822 ?

'needs C' simply because it's slightly shorter or 'C skills'?

[anatoly techtonik]

Post by Nick Coghlan
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
- 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
1. Does the extra keyword sound useful?
2. Any other suggestions for a name?
Cheers,
Nick.

+1 as a complete no brainer from my viewpoint. As an example wouldn't it
help here http://bugs.python.org/issue13822 ?
'needs C' simply because it's slightly shorter or 'C skills'?

needs_c is better, because it is more easily exportable into external
tracking systems that use real words as keywords. Also, it is less
fragile (more accurate) when used in search queries (especially with
external search and through OpenSearch API).

The idea is good.

[Ezio Melotti]

Hi,

Post by Nick Coghlan
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
- 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
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.

Best Regards,
Ezio Melotti

Post by Nick Coghlan
2. Any other suggestions for a name?
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

[Nick Coghlan]

Post by Ezio Melotti
Hi,

Post by Nick Coghlan
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
- 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
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>