From ncoghlan at gmail.com Sun Aug 3 15:23:49 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Sun, 3 Aug 2014 23:23:49 +1000 Subject: [core-workflow] Adding a "requires C" keyword? Message-ID: 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 at gmail.com | Brisbane, Australia From francismb at email.de Sun Aug 3 16:48:46 2014 From: francismb at email.de (francis) Date: Sun, 03 Aug 2014 16:48:46 +0200 Subject: [core-workflow] Adding a "requires C" keyword? In-Reply-To: References: Message-ID: <53DE4BCE.8020409@email.de> Hi Nick, > 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? 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 From breamoreboy at yahoo.co.uk Sun Aug 3 18:02:48 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Sun, 03 Aug 2014 17:02:48 +0100 Subject: [core-workflow] Adding a "requires C" keyword? In-Reply-To: References: Message-ID: On 03/08/2014 14:23, Nick Coghlan 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? > 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'? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence From techtonik at gmail.com Sun Aug 3 19:48:52 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Sun, 3 Aug 2014 20:48:52 +0300 Subject: [core-workflow] Adding a "requires C" keyword? In-Reply-To: References: Message-ID: On Sun, Aug 3, 2014 at 7:02 PM, Mark Lawrence wrote: > On 03/08/2014 14:23, Nick Coghlan 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? >> 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. From francismb at email.de Sun Aug 3 21:19:35 2014 From: francismb at email.de (francis) Date: Sun, 03 Aug 2014 21:19:35 +0200 Subject: [core-workflow] Stage and keywords differences Message-ID: <53DE8B47.8020405@email.de> 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 From ezio.melotti at gmail.com Mon Aug 4 00:45:13 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 4 Aug 2014 01:45:13 +0300 Subject: [core-workflow] Stage and keywords differences In-Reply-To: <53DE8B47.8020405@email.de> References: <53DE8B47.8020405@email.de> Message-ID: Hi, On Sun, Aug 3, 2014 at 10:19 PM, francis wrote: > Dear core-devs, > I would like to ask about the differences between (from the devguide [1]): > a) stage:needs patch and keywords:patch Stage can only be set by "Developers", the "patch" keyword can be added by anyone and it's added automatically when a file is attached to an issue. > b) stage:patch review and keywords:needs review > As above, but the "needs review" keyword is not added automatically. > Aren't those redundant? Why are those keywords needed? They are somewhat redundant, but the keywords allow regular users to signal that an issue needs review and/or has a patch. I don't know if this is the reason they were added in the first place, but removing them and make the stage settable by everyone would be fine with me. Note that doing this will break a few things that look for the "patch" keyword, including the weekly report, the detector that sets the "patch" keyword, possibly the "issues with patch" query in the sidebar, a meta-tracker patch we made yesterday at the Helsinki sprint[0], and perhaps other tools. Updating these things is not difficult though. Best Regards, Ezio Melotti [0]: http://psf.upfronthosting.co.za/roundup/meta/issue550 -- Add an icon to the issue list for issues with patches > 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 From ezio.melotti at gmail.com Mon Aug 4 01:37:38 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Mon, 4 Aug 2014 02:37:38 +0300 Subject: [core-workflow] Adding a "requires C" keyword? In-Reply-To: References: Message-ID: Hi, On Sun, Aug 3, 2014 at 4:23 PM, Nick Coghlan 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. Best Regards, Ezio Melotti > 2. Any other suggestions for a name? > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From ncoghlan at gmail.com Mon Aug 4 01:47:18 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 4 Aug 2014 09:47:18 +1000 Subject: [core-workflow] Adding a "requires C" keyword? In-Reply-To: References: Message-ID: On 4 Aug 2014 09:37, "Ezio Melotti" wrote: > > Hi, > > On Sun, Aug 3, 2014 at 4:23 PM, Nick Coghlan 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: From techtonik at gmail.com Mon Aug 4 08:52:22 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 4 Aug 2014 09:52:22 +0300 Subject: [core-workflow] Stage and keywords differences In-Reply-To: References: <53DE8B47.8020405@email.de> Message-ID: On Mon, Aug 4, 2014 at 1:45 AM, Ezio Melotti wrote: > On Sun, Aug 3, 2014 at 10:19 PM, francis wrote: >> Dear core-devs, >> I would like to ask about the differences between (from the devguide [1]): >> a) stage:needs patch and keywords:patch > > Stage can only be set by "Developers", the "patch" keyword can be > added by anyone and it's added automatically when a file is attached > to an issue. > >> b) stage:patch review and keywords:needs review >> > > As above, but the "needs review" keyword is not added automatically. > >> Aren't those redundant? Why are those keywords needed? > > They are somewhat redundant, but the keywords allow regular users to > signal that an issue needs review and/or has a patch. > I don't know if this is the reason they were added in the first place, > but removing them and make the stage settable by everyone would be > fine with me. +1 on above, except that patch keyword should stay. stage:needs patch + keyword:patch can be switched automatically to stage:needs review. > Note that doing this will break a few things that look for the "patch" > keyword, including the weekly report, the detector that sets the > "patch" keyword, possibly the "issues with patch" query in the > sidebar, a meta-tracker patch we made yesterday at the Helsinki > sprint[0], and perhaps other tools. Updating these things is not > difficult though. patch is not a stage, it is a property of the issue that is useful even after stage is set to resolved. From antoine at python.org Thu Aug 14 17:21:07 2014 From: antoine at python.org (Antoine Pitrou) Date: Thu, 14 Aug 2014 11:21:07 -0400 Subject: [core-workflow] Pre-fill some fields when unfilled? Message-ID: 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. From techtonik at gmail.com Tue Aug 26 11:48:12 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Tue, 26 Aug 2014 12:48:12 +0300 Subject: [core-workflow] PEP awareness statistics Message-ID: 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. From guido at python.org Tue Aug 26 16:46:11 2014 From: guido at python.org (Guido van Rossum) Date: Tue, 26 Aug 2014 07:46:11 -0700 Subject: [core-workflow] PEP awareness statistics In-Reply-To: References: Message-ID: I like the idea of adding feedback buttons to the website (not just the PEPs). I'm not sure how much you can get people vote with that much though. Maybe just a yes/no (like MSDN does) or a star-rating (1-5)? On Tue, Aug 26, 2014 at 2:48 AM, anatoly techtonik wrote: > 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. > _______________________________________________ > core-workflow mailing list > core-workflow at python.org > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Wed Aug 27 09:59:33 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 27 Aug 2014 17:59:33 +1000 Subject: [core-workflow] PEP awareness statistics In-Reply-To: References: Message-ID: As Anatoly has chosen to ignore my request that he refrain from participating in this group, I am now unsubscribing from this list. As he has not specifically misbehaved here, there are no grounds to ban him from it. However, I refuse to work with someone that has repeatedly demonstrated such a complete lack of respect for my time and energy, and a fundamental disagreement with the open source principle of "those that do the work, make the rules". Regards, Nick. From techtonik at gmail.com Fri Aug 29 19:14:39 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Fri, 29 Aug 2014 20:14:39 +0300 Subject: [core-workflow] PEP awareness statistics In-Reply-To: References: Message-ID: Sorry for a long delay. I can't ignore Nick's opinion, but I leave it into separate mails, because it raises two issues that are off subject for current thread (and hijack it). However, I'd like to thank him for his personal choice of leaving the freedom to express opinion to me. I am not as evil as it looks like, so at some point it will be possible to get back to dialog. Back to the idea of replacing feedback controls with more simple buttons. There is no data, but I think that people who understand what these controls are for, and who cared to read PEP till the end, will use them properly no matter how many controls there are. This is the most accessible way how can they communicate the feedback. I am not sure about quick ratings. What message does a rating carry? 1-5 - is it a quality of PEP, its clarity, or a general rating of the idea of PEP? It doesn't tell much neither to me, as a voter, not to me, as a writer. Yes/No is extreme, but surprisingly, a good choice for simplicity. PEP fixes things in stone, so saying No is a clear indication that there are moments you disagree with. Making it personal makes it possible to find and ask why, but it is a hassle, so better leave a way to leave feedback immediately. About comments. Comment is an obvious way to go, but comments are not editable and you won't be able to change an opinion later. Editable personal note, which is not a comment, might be a better choice. I see two kind of notes. Both of them probably public, but one - let's call this `opinion` on version - is used to gather overall impression of response to PEP. Another type of not - let's call it personal `status` note - this carries notes for yourself that are important during PEP review (and would be nice if those were backed up by operational transformation stuff like Etherpad-lite, so that when you're interrupted in the middle and forgot to save, your information is not lost). For simplicity, however, this can be replaced by a simple message. Ideally message form can come with its own feedback loop, which is in its most simple form a pointer to this group and an explanation note that usefullness and usability of the feedback process over PEP is researched, discussed and developed here, so feedback on that is also welcome. On Tue, Aug 26, 2014 at 5:46 PM, Guido van Rossum wrote: > I like the idea of adding feedback buttons to the website (not just the > PEPs). I'm not sure how much you can get people vote with that much though. > Maybe just a yes/no (like MSDN does) or a star-rating (1-5)? > > > On Tue, Aug 26, 2014 at 2:48 AM, anatoly techtonik > wrote: >> >> 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. >> _______________________________________________ >> core-workflow mailing list >> core-workflow at python.org >> https://mail.python.org/mailman/listinfo/core-workflow >> This list is governed by the PSF Code of Conduct: >> https://www.python.org/psf/codeofconduct > > > > > -- > --Guido van Rossum (python.org/~guido) -- anatoly t. From breamoreboy at yahoo.co.uk Fri Aug 29 21:21:12 2014 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Fri, 29 Aug 2014 20:21:12 +0100 Subject: [core-workflow] PEP awareness statistics In-Reply-To: References: Message-ID: On 27/08/2014 08:59, Nick Coghlan wrote: > As Anatoly has chosen to ignore my request that he refrain from > participating in this group, I am now unsubscribing from this list. > > As he has not specifically misbehaved here, there are no grounds to > ban him from it. However, I refuse to work with someone that has > repeatedly demonstrated such a complete lack of respect for my time > and energy, and a fundamental disagreement with the open source > principle of "those that do the work, make the rules". > > Regards, > Nick. I'm joining you, bye folks. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence