Mailman 3 August 2014 - core-workflow

PEP awareness statistics
by anatoly techtonik 29 Aug '14

29 Aug '14

Hi, In order to improve workflow it is important to collect data about the process. Even if Python doesn't have any kind of democracy, meritocracy or other kind of political system (well, dictatorship?), it is nice to estimate how many people are really involved in the process of language evolution. For example, there is a new accepted PEP 440 which is authored by two people (documented in PEP), and they are are listed in credits. They definitely put a lot of work in making it happen. Other people had less chances to monitor the progress, and in my opinion this is the reason why handling semantic versioning was not given enough attention - proposing to convert versions instead of specifying mechanism for packages to specify alternative versioning system: http://legacy.python.org/dev/peps/pep-0440/#semantic-versioning But, my opinion is an opinion and it will stay so until it is backed up by data that can put some weight to my words. This can be possible if PEP pages allowed people with registered accounts to provide structured feedback for PEP in a form of three metrics: % of text read - 0 .. 100% (approximate) Text clarity - 0 .. 5 (how hard to understand the text) PEP coverage - 0 .. 5 (does the PEP cover your case well) Accept / Reject / Clarify / meh. Optional (reason/comment): -- anatoly t.

4 4

Pre-fill some fields when unfilled?
by Antoine Pitrou 14 Aug '14

14 Aug '14

Hello, When I select "enhancement" it would be nice for the version to be filled with the current dev version. Also, the pre-filled priority should probably be "normal". (I've been using a laptop's keyboard and trackpad for some time, so I'm becoming more sensitive to the number of UI actions necessary to interact with the bug tracker :-)) Regards Antoine.

1 0

Stage and keywords differences
by francis 04 Aug '14

04 Aug '14

Dear core-devs, I would like to ask about the differences between (from the devguide [1]): a) stage:needs patch and keywords:patch b) stage:patch review and keywords:needs review Aren't those redundant? Why are those keywords needed? IMHO the keywords ones could be refactored out. Doesn't a issue that's on stage:needs patch be marked “without patch” (not marked in that case) and some that is on stage:patch review or above be always marked as “keywords:patch” …? Thanks in advance! Regards, francis ---- [1] https://docs.python.org/devguide/triaging.html

3 2

Adding a "requires C" keyword?
by Nick Coghlan 03 Aug '14

03 Aug '14

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. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 5

core-workflow August 2014