From taleinat at gmail.com Thu May 1 10:21:59 2014 From: taleinat at gmail.com (Tal Einat) Date: Thu, 1 May 2014 11:21:59 +0300 Subject: [core-workflow] workflow types: agile (gameplay) vs rigid (process) In-Reply-To: References: Message-ID: Anatoly, First of all, your post is off-topic for this list. We are here to discuss the workflow of core Python development and related tools, not to have general discussions about workflow. Next, using a title such as "agile (gameplay) vs rigid (process)" is inflammatory (= will make people angry) but uninformative and unhelpful. Furthermore, to the extent of my understanding of the relevant terms, you show a complete misunderstanding of them. Here are some specific examples: > Agile workflows often take into account > personalities, habits and environment of people > involved in a process. I have never encountered a workflow which specifically takes into account personalities and habits. In my opinion it is silly to say that agile workflows take personalities and habits into account while other workflows do not. On the other hand, regardless of workflow, any specific development group should take into account many considerations, including the environment and its members' personalities and habits. This has nothing to do with workflow, so I simply cannot make any sense of your above statement. > Just think about why different people don't feel fun > contributing to Python overall, who are those people, > why Python community needs them, and how you > can help them by removing obstacles. This is precisely what the Python developers and the PSF have always done. Specifically, in recent years they have been spending more and more time and effort on this. Despite this you have repeatedly (now and in the past) accused them all of not doing so, and you are simply completely *wrong*. This just shows how distorted your view of the Python developers is. > workflow types: agile (gameplay) vs rigid (process) This is ridiculous. Every agile methodology I have heard of includes some specific process for development. From all of the development groups I have been in or worked with, those which used "agile" methods had much clearer processes which they actually stuck to and which were usually more effective. "Agile" does not mean not taking work seriously and it is not an excuse for lack of process. Perhaps you have met some developers who used "agile" as an excuse for not defining processes, but you would be wrong to think this is true of all other groups who use "agile" methods. To summarize, this post is off-topic, inflammatory and contains several grossly incorrect statements. In my opinion this discussion should not continue here. - Tal Einat From rdmurray at bitdance.com Mon May 5 17:24:47 2014 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 05 May 2014 11:24:47 -0400 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <20140424212305.1C557250D5D@webabinitio.net> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> Message-ID: <20140505152448.5DD2D250D4E@webabinitio.net> I'm a week later than I expected, but I've added my notes to the discussion summary started by Ezio at: https://wiki.python.org/moin/TrackerDevelopmentPlanning Based on the feedback, I propose two major changes compared to my initial proposal. The first is to combine 'keywords' and 'component' into a single tags field, which will include all the labels from the experts index. Types is reduced to *just* documentation/bug/enhancement, everything else is a tag. Likewise priority is reduced to just high/normal/low, and release-blocker and deferred-blocker become per-release tags. I think the tags should at least initially be a fixed set (that is, normal users can't add tags). The second major change is that I think we should defer the decision about how to manage patches until we can experiment with some possibilities. In particular, Ezio has some preliminary code to do content analysis on patches, and I think we should experiment with incorporating that, and try out a couple of different ways of managing patches once we have that automated analysis working. Ezio made some notes about this on the document. Although this wasn't discussed directly, I also removed 'committer decision needed' from the list of states, leaving just 'decision needed'. The various 'closed/xxx' items can at least for now (and probably forever) continue to be a 'closed' state plus the (simplified) 'resolution'. Given this, it would be quite practical to simply change 'stage' list from its current value to what I propose for the new state. That means it would look like this: - no selection - (that is: new) information needed decision needed patch needed review needed patch update needed commit review needed resolved We can then add reactors (and javascript) such that changing an issue stage to 'resolved' also closes it, and that changing an issue status to 'closed' resolves it, and vice versa (re-opening an issue goes to, say, 'patch needed' if no specific stage is set; changing the stage reopens the issue). This will make it easy to implement the new state scheme and build the UI for the queues &c, and when we are ready to cut over to the new UI, we can retire 'status'. If this is deemed acceptable, then I would propose that we (a) go ahead and make that change, (b) make the change to the 'assigned to' field, (which we are currently not using much at all), (c) add code to the existing UI to allow regular users to make the state (stage) transitions as outlined in my proposal, and (d) add the dashboard UI for getting optimal access to the resulting queues. These changes are really the heart of my proposal, and would get us a lot of the benefit, even before we optimize the UI. --David From willingc at willingconsulting.com Mon May 5 23:56:09 2014 From: willingc at willingconsulting.com (Carol Willing) Date: Mon, 05 May 2014 14:56:09 -0700 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <20140505152448.5DD2D250D4E@webabinitio.net> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> Message-ID: <536808F9.7090003@willingconsulting.com> Hello David, I would like to offer my thoughts as a new Python contributor. I may be new as a Python contributor but I've been involved in programming, managing, and teaching a variety of computer languages and operating systems since the mid-1970s. As I have not met many of you personally, I would like to thank each of you for your contributions to Python. It's truly my pleasure to use Python. I have a couple of brief comments on Tracker planning from the perspective of a new contributor (though someone with an understanding of software development processes). Three different pieces of information are most valuable to me as a brand new contributor (i.e. someone without any special privileges to change status or fields in an issue): 1. Current state 2. Next action step 3. Next action step claimed by:___________ and on what date_________ Ideally, these three pieces of information will answer the new person's questions: 1. What is this issue's current status? 2. What next step could I take to move this issue along to the next desired state? 3. Is the next step something that is free to work on (unclaimed) or stalled? What can I do to claim the next action step? For example, an issue might have a current state of "Reproduced issue successfully" and the next action step might be "Update documentation" or "Create patch". Here's a write up of how I found the contribution process and how I would explain the process to others based on my experience: http://pastebin.com/iKhL5RvS I'm not asking you to change or modify the process as it stands, but merely to consider the process from the perspective of someone who would like to contribute but is new to Python's specific workflow. Thanks, Carol Willing -- Carol Willing Developer Willing Consulting From ncoghlan at gmail.com Tue May 6 00:56:05 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 6 May 2014 08:56:05 +1000 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <536808F9.7090003@willingconsulting.com> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536808F9.7090003@willingconsulting.com> Message-ID: On 6 May 2014 08:42, "Carol Willing" wrote: > Here's a write up of how I found the contribution process and how I would explain the process to others based on my experience: > http://pastebin.com/iKhL5RvS Thanks Carol, that's a great write-up and definitely includes some good ideas for improvement. For folks with greater Roundup-fu than me: how hard does the "personal tags" idea sound? Alternatively, the front end could be more like a personal set of "issue lists". Cheers, Nick. > > I'm not asking you to change or modify the process as it stands, but merely to consider the process from the perspective of someone who would like to contribute but is new to Python's specific workflow. > > Thanks, > Carol Willing > > -- > Carol Willing > Developer > Willing Consulting > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Tue May 6 02:13:38 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Tue, 6 May 2014 03:13:38 +0300 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <20140505152448.5DD2D250D4E@webabinitio.net> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> Message-ID: Hi, On Mon, May 5, 2014 at 6:24 PM, R. David Murray wrote: > I'm a week later than I expected, but I've added my notes to the > discussion summary started by Ezio at: > > https://wiki.python.org/moin/TrackerDevelopmentPlanning > > Based on the feedback, I propose two major changes compared to my > initial proposal. > > The first is to combine 'keywords' and 'component' into a single > tags field, which will include all the labels from the experts index. A few questions: 1) should we merge the keywords into components, do the opposite, or create a brand new "tags" field? 2) how are we going to migrate metadata from the old format to the new one? 3) with "all the labels from the experts index" you mean every single entry? There are quite a lot of entries (all the modules, platforms, interest areas: https://docs.python.org/devguide/experts.html ); 4) how should this look without js? similar to the nosy list (input box, without autocomplete), or select/option like the one we currently have for components/keywords (entries can be grouped, but they are still a lot); And a few comments: 1) tags/labels should be color-coded so that each group has a different color (module, platform, component, general, release, etc..), if they are not too many they could be showed in the issue list too (think about gmail labels); 2) the autonosy should be revised once we do this. One idea is to suggest people to add (Something along the lines of 'You selected the module tag "html", suggested dev: [ezio.melotti]'). The other idea is to handle this automatically -- on the expert index with have a * to allow assignment, we might do something for nosy too and use this to handle autonosy/autoassign. Otherwise we can just edit autonosy/autoassign like we currently do (manually from roundup), but with more available tags; > Types is reduced to *just* documentation/bug/enhancement, everything > else is a tag. Likewise priority is reduced to just high/normal/low, > and release-blocker and deferred-blocker become per-release tags. > > I think the tags should at least initially be a fixed set (that is, > normal users can't add tags). > +1 for fixed set. Free tags might lead to redundant or misspelled tags (and possibly things like #ibrokepython #lolsegfault #yolo). We could add tags if we think they are useful, but if we want to add free tags they should be in a separate category with their own color code and an easy way to moderate them. > The second major change is that I think we should defer the decision about > how to manage patches until we can experiment with some possibilities. > In particular, Ezio has some preliminary code to do content analysis > on patches, and I think we should experiment with incorporating that, > and try out a couple of different ways of managing patches once we have > that automated analysis working. Ezio made some notes about this on > the document. > My latest experiment is: http://wolfprojects.altervista.org/patches.html (requires js). This includes a few ideas: 1) detecting if the patch has tests/docs/news/acks (see last column on the right); 2) detecting the files it affects (second last column on the right; could be used for module auto-tagging); 3) having a simple way to filter/inspect patches in real time with js; 1 and 2 should be integrated on the issue page, 3 could be done on a separate page. Since 3 looked like an interesting idea (it makes search a lot easier -- you can just filter/group for user name, files, issue, etc on the fly), I also put together a proof of concept for a similar interface that could replace the main issue list (and/or be used in the dashboard): http://wolfprojects.altervista.org/issue.index.html To implement this we just need a fixed page and feed issues to it via ajax/json. With a bit of caching we can make the whole thing very efficient (no need to build the page server-side every time, less data moving on the network, real-time client-side filtering/grouping/searching, no need to go back and forth from the search page to refine queries) so the idea has lot of potential. While this is not too difficult to implement, it still requires some work, so for now it's low priority. > Although this wasn't discussed directly, I also removed 'committer > decision needed' from the list of states, leaving just 'decision needed'. Are there limitations on who can change the stage from "decision needed" to something else? ISTM that if a user provides information he can move the stage to "decision needed" or if he provides a patch he can move the stage to "review needed", but do we want them to add their opinion and move it from "decision needed" to something else? Also is it expected that we move back to previous stages (e.g. going back to "decision needed" after a few different patches have been proposed) or you were thinking about a more linear evolution? > The various 'closed/xxx' items can at least for now (and probably forever) > continue to be a 'closed' state plus the (simplified) 'resolution'. > Given this, it would be quite practical to simply change 'stage' list > from its current value to what I propose for the new state. That means > it would look like this: > > - no selection - (that is: new) > information needed > decision needed > patch needed > review needed > patch update needed > commit review needed > resolved > > We can then add reactors (and javascript) such that changing an issue > stage to 'resolved' also closes it, and that changing an issue status to > 'closed' resolves it, and vice versa (re-opening an issue goes to, say, > 'patch needed' if no specific stage is set; changing the stage reopens > the issue). This will make it easy to implement the new state scheme > and build the UI for the queues &c, and when we are ready to cut over > to the new UI, we can retire 'status'. > > If this is deemed acceptable, then I would propose that we (a) go > ahead and make that change, that == the list of stages you suggested? > (b) make the change to the 'assigned to' > field, (which we are currently not using much at all), So make it possible to assign the issue to everyone and then start using it like this? > (c) add code to the existing UI to allow regular users to make the state (stage) > transitions as outlined in my proposal, For this we need to change the schema too, since currently users are not allowed to change the stage. Regarding the UI changes, what exactly do you want to change? > and (d) add the dashboard UI > for getting optimal access to the resulting queues. Adding a new page for this can be done quite easily, getting the queries right might be a bit more complicated (I think we shouldn't use sql directly, and not all the values are easily accessible from the Roundup API). > These changes are > really the heart of my proposal, and would get us a lot of the benefit, > even before we optimize the UI. > It would be good to set up an online test tracker where we can push/test changes live, get some feedback, and then apply the change that works best to the real tracker. This would make things much easier, so I would give higher priority to this. Having some tentative mockups for the new interface would also help get a better idea, especially if we can get some designer to help us out (that could be done later once we decided the fields we want though). > --David From ezio.melotti at gmail.com Tue May 6 02:33:28 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Tue, 6 May 2014 03:33:28 +0300 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536808F9.7090003@willingconsulting.com> Message-ID: On Tue, May 6, 2014 at 1:56 AM, Nick Coghlan wrote: > > On 6 May 2014 08:42, "Carol Willing" wrote: >> Here's a write up of how I found the contribution process and how I would >> explain the process to others based on my experience: >> http://pastebin.com/iKhL5RvS > > Thanks Carol, that's a great write-up and definitely includes some good > ideas for improvement. > > For folks with greater Roundup-fu than me: how hard does the "personal tags" > idea sound? Alternatively, the front end could be more like a personal set > of "issue lists". > I haven't read Carol's link yet, but if with "personal tags" you mean tags hat a single user can add for himself to an issue and that are not visible to others, then I think it might be somewhat difficult. You could store them in a user field (e.g. user.personal_tags = {issue123: [tag1, tag2], issue124: [tag3]}) but then it might not be too easy to access them (e.g. while searching). Same goes if we keep them in a separate table. In addition, we also have to write the code to handle addition/deletion of both tags in a personal list, and on the issue. A possible compromise might be to add a way to "star" interesting issues. I think there are 3 "levels", and we currently support only two: 1) If I know I'm going to fix an issue, I assign it to myself; 2) if I know how to fix an issue, or I would like to work on it, I have to mark it on my mail client; 3) if I left a comment or a review or even if an issue is "interesting", I add myself to nosy; If you were referring to "a way to easily tag issues to return to as promising possibilities", then a star/favorite feature might cover case 2) and solve the issue, and even if it's not as fine grained as a full personal tags system, it should be simpler to implement. > Cheers, > Nick. > >> >> I'm not asking you to change or modify the process as it stands, but >> merely to consider the process from the perspective of someone who would >> like to contribute but is new to Python's specific workflow. >> >> Thanks, >> Carol Willing >> >> -- >> Carol Willing >> Developer >> Willing Consulting >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 From willingc at willingconsulting.com Tue May 6 16:33:26 2014 From: willingc at willingconsulting.com (Carol Willing) Date: Tue, 06 May 2014 07:33:26 -0700 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536808F9.7090003@willingconsulting.com> Message-ID: <5368F2B6.9000904@willingconsulting.com> Ezio and Nick, Thanks for the feedback on the tracker. A couple of more thoughts on "personal tags" which hopefully will clarify and save work and time. FWIW, I believe the data to determine easily the state of an issue, the next action required on the issue, and if the issue is free to work on are most important to a new contributor. A simple "star/favorite" issue toggle was really the extent of what I was thinking would have been helpful. >>> For folks with greater Roundup-fu than me: how hard does the "personal tags" >>> idea sound? Alternatively, the front end could be more like a personal set >>> of "issue lists". >>> "a way to easily tag issues to return to as >>> promising possibilities", then a star/favorite feature might cover >>> case 2) and solve the issue, and even if it's not as fine grained as >>> a full personal tags system, it should be simpler to implement. Ezio's links to his experiments with alternate displays of information reminded me of something that I thought about when searching for a suitable new contributor issue. http://wolfprojects.altervista.org/patches.html (requires js) When I was looking for an issue to work on, I tried a number of search criteria (easy, new, documentation, testing). It's possible that my "search"-fu is lacking, yet I had a difficult time identifying a "bite sized" issue related to documentation, testing, or development in either C or Python that didn't appear to be actively worked on or very old. I suspect there were a number of suitable issues yet it felt like searching for a needle in a very large haystack. At the time I wondered if it just wouldn't be easier to grab the entire "csv" file of issues and use ipython notebook with numpy/pandas to run interactive searches for issues. Instead, I wound up just randomly reading issues from the tracker which was why a "star/tag" would have been helpful. In hindsight, I suspect if I used the entire csv file with appropriate search criteria in numpy/pandas that I would have greatly simplified my search for an issue. I may do this now so I can see if I can find search criteria that would be useful for new contributors to identify suitable issues for: * documentation * increasing test coverage[pulling from the coverage site] * triaging[identifying specific tasks that someone without developer status can do to add value]). Thanks, Carol -- Carol Willing Developer Willing Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Tue May 6 17:09:03 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Tue, 6 May 2014 18:09:03 +0300 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <5368F2B6.9000904@willingconsulting.com> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536808F9.7090003@willingconsulting.com> <5368F2B6.9000904@willingconsulting.com> Message-ID: On Tue, May 6, 2014 at 5:33 PM, Carol Willing wrote: > Ezio and Nick, > > Thanks for the feedback on the tracker. A couple of more thoughts on > "personal tags" which hopefully will clarify and save work and time. FWIW, I > believe the data to determine easily the state of an issue, the next action > required on the issue, and if the issue is free to work on are most > important to a new contributor. > > A simple "star/favorite" issue toggle was really the extent of what I was > thinking would have been helpful. > For me it would be OK to add it, since I needed it myself more than once. > For folks with greater Roundup-fu than me: how hard does the "personal tags" > idea sound? Alternatively, the front end could be more like a personal set > of "issue lists". > > "a way to easily tag issues to return to as > promising possibilities", then a star/favorite feature might cover > case 2) and solve the issue, and even if it's not as fine grained as > a full personal tags system, it should be simpler to implement. > > Ezio's links to his experiments with alternate displays of information > reminded me of something that I thought about when searching for a suitable > new contributor issue. > > http://wolfprojects.altervista.org/patches.html (requires js) > > > When I was looking for an issue to work on, I tried a number of search > criteria (easy, new, documentation, testing). It's possible that my > "search"-fu is lacking, yet I had a difficult time identifying a "bite > sized" issue related to documentation, testing, or development in either C > or Python that didn't appear to be actively worked on or very old. I suspect > there were a number of suitable issues yet it felt like searching for a > needle in a very large haystack. > The haystack is very large (we are approaching 5000 open issues). hopefully tags (including the "bite sized" one proposed by David) will make search easier. My experiment, if properly implemented, will make search faster (it's possible to search for individual columns too if we want). This will allow to refine searches until you find something interesting. > At the time I wondered if it just wouldn't be easier to grab the entire > "csv" file of issues and use ipython notebook with numpy/pandas to run > interactive searches for issues. Instead, I wound up just randomly reading > issues from the tracker which was why a "star/tag" would have been helpful. > The short answer is probably no. The main problem is that the csv only includes ids for the different fields. So instead of having "open", "closed", "pending" in the status column you have e.g. "1", "2", "3". You can find the corresponding value or each id, but then you have to replace them and it starts taking more time. The second link I posted (http://wolfprojects.altervista.org/issue.index.html) is generated from the csv (as it was just a proof of concept I put together in 5 minutes), so it only has the ids and it's not updated with the latest issues. The csv might also not contain all the information you need, even though you can decide which columns should be included by fiddling with the URL. > In hindsight, I suspect if I used the entire csv file with appropriate > search criteria in numpy/pandas that I would have greatly simplified my > search for an issue. I may do this now so I can see if I can find search > criteria that would be useful for new contributors to identify suitable > issues for: > > documentation > increasing test coverage[pulling from the coverage site] > triaging[identifying specific tasks that someone without developer status > can do to add value]). > If you still want to try, you should be able to see the corresponding values for each id at the following URLs: http://bugs.python.org/component ("documentation" is 4) http://bugs.python.org/stage ("need test" is 2, "need patch" is 3, "no value" should be -1) > Thanks, > Carol > > > > -- > Carol Willing > Developer > Willing Consulting From bcannon at gmail.com Wed May 7 15:39:27 2014 From: bcannon at gmail.com (Brett Cannon) Date: Wed, 07 May 2014 13:39:27 +0000 Subject: [core-workflow] Tracker workflow proposal References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> Message-ID: On Mon May 05 2014 at 11:54:18 AM, R. David Murray wrote: > I'm a week later than I expected, but I've added my notes to the > discussion summary started by Ezio at: > > https://wiki.python.org/moin/TrackerDevelopmentPlanning > > Based on the feedback, I propose two major changes compared to my > initial proposal. > > The first is to combine 'keywords' and 'component' into a single > tags field, which will include all the labels from the experts index. > Types is reduced to *just* documentation/bug/enhancement, everything > else is a tag. Likewise priority is reduced to just high/normal/low, > and release-blocker and deferred-blocker become per-release tags. > > I think the tags should at least initially be a fixed set (that is, > normal users can't add tags). > SGTM. I know Ezio pointed out the list will be long, but since triagers will be the ones typically setting the field it shouldn't be an issue. > > The second major change is that I think we should defer the decision about > how to manage patches until we can experiment with some possibilities. > In particular, Ezio has some preliminary code to do content analysis > on patches, and I think we should experiment with incorporating that, > and try out a couple of different ways of managing patches once we have > that automated analysis working. Ezio made some notes about this on > the document. > > Although this wasn't discussed directly, I also removed 'committer > decision needed' from the list of states, leaving just 'decision needed'. > The various 'closed/xxx' items can at least for now (and probably forever) > continue to be a 'closed' state plus the (simplified) 'resolution'. > Given this, it would be quite practical to simply change 'stage' list > from its current value to what I propose for the new state. That means > it would look like this: > > - no selection - (that is: new) > information needed > decision needed > patch needed > review needed > patch update needed > commit review needed > resolved > > We can then add reactors (and javascript) such that changing an issue > stage to 'resolved' also closes it, and that changing an issue status to > 'closed' resolves it, and vice versa (re-opening an issue goes to, say, > 'patch needed' if no specific stage is set; changing the stage reopens > the issue). This will make it easy to implement the new state scheme > and build the UI for the queues &c, and when we are ready to cut over > to the new UI, we can retire 'status'. > Also SGTM. -Brett > > If this is deemed acceptable, then I would propose that we (a) go > ahead and make that change, (b) make the change to the 'assigned to' > field, (which we are currently not using much at all), (c) add code > to the existing UI to allow regular users to make the state (stage) > transitions as outlined in my proposal, and (d) add the dashboard UI > for getting optimal access to the resulting queues. These changes are > really the heart of my proposal, and would get us a lot of the benefit, > even before we optimize the UI. > > --David > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at willingconsulting.com Wed May 7 17:09:03 2014 From: willingc at willingconsulting.com (Carol Willing) Date: Wed, 07 May 2014 08:09:03 -0700 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> Message-ID: <536A4C8F.3050606@willingconsulting.com> I'm wondering if "decision needed" might be more accurately named "triage needed"? Looking at David's well documented proposals and other mail comments, "triage needed" more specifically describes the 'state'. A few thoughts: 1. "Triage needed" would raise the importance and visibility of the triage contributor role. A positive for onboarding and growing development talent. 2. "Triage needed" is more descriptive and clearer than "decision needed" especially for those users that do not read documentation or understand the development workflow. "Decision needed" implies that a decision will be made to include or not include in a release. Realistically, decisions are made throughout the remainder of the development process based on time, resources, etc. Thanks, Carol On 5/7/14, 6:39 AM, Brett Cannon wrote: > > On Mon May 05 2014 at 11:54:18 AM, R. David Murray > > wrote: > > > Given this, it would be quite practical to simply change 'stage' list > from its current value to what I propose for the new state. That > means > it would look like this: > > - no selection - (that is: new) > information needed > decision needed > patch needed > review needed > patch update needed > commit review needed > resolved > -- Carol Willing Developer Willing Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmurray at bitdance.com Wed May 7 17:59:29 2014 From: rdmurray at bitdance.com (R. David Murray) Date: Wed, 07 May 2014 11:59:29 -0400 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <536A4C8F.3050606@willingconsulting.com> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> Message-ID: <20140507155929.D2AA6250D68@webabinitio.net> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing wrote: > I'm wondering if "decision needed" might be more accurately named > "triage needed"? > > Looking at David's well documented proposals and other mail comments, > "triage needed" more specifically describes the 'state'. > > A few thoughts: > > 1. "Triage needed" would raise the importance and visibility of the > triage contributor role. A positive for onboarding and growing > development talent. > > 2. "Triage needed" is more descriptive and clearer than "decision > needed" especially for those users that do not read documentation or > understand the development workflow. "Decision needed" implies that a > decision will be made to include or not include in a release. > Realistically, decisions are made throughout the remainder of the > development process based on time, resources, etc. I'll be interested in what others think, but to me "decision needed" is closer than "triage needed". That is, the state means that someone other than the person moving the issue to that state needs to make a decision. That decision can be "Is this something we consider a bug? What releases can we fix this in given our backward compatibility requirements? Is this an acceptable enhancement? And any other decision that needs to be made before the issue can move forward. All of these *can* be "triage" decisions, but to my ear it is the word "triage" that is more about deciding where to allocate resources ("which release"), whereas we generally don't work that way. We just decide if it can go in or not, and if the patch is ready before the next release, it can go in. More specifically, because I removed 'committer decision needed', 'decision needed' covers the case of needing a committer decision, which is by definition not a triage decision :) Perhaps 'committer decision needed' should be kept after all? --David From ncoghlan at gmail.com Thu May 8 00:58:16 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 8 May 2014 08:58:16 +1000 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <20140507155929.D2AA6250D68@webabinitio.net> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> Message-ID: On 8 May 2014 01:59, "R. David Murray" wrote: > > On Wed, 07 May 2014 08:09:03 -0700, Carol Willing < willingc at willingconsulting.com> wrote: > > I'm wondering if "decision needed" might be more accurately named > > "triage needed"? > > > > Looking at David's well documented proposals and other mail comments, > > "triage needed" more specifically describes the 'state'. > > > > A few thoughts: > > > > 1. "Triage needed" would raise the importance and visibility of the > > triage contributor role. A positive for onboarding and growing > > development talent. > > > > 2. "Triage needed" is more descriptive and clearer than "decision > > needed" especially for those users that do not read documentation or > > understand the development workflow. "Decision needed" implies that a > > decision will be made to include or not include in a release. > > Realistically, decisions are made throughout the remainder of the > > development process based on time, resources, etc. > > I'll be interested in what others think, but to me "decision needed" is > closer than "triage needed". That is, the state means that someone other > than the person moving the issue to that state needs to make a decision. > That decision can be "Is this something we consider a bug? What releases > can we fix this in given our backward compatibility requirements? > Is this an acceptable enhancement? And any other decision that needs > to be made before the issue can move forward. > > All of these *can* be "triage" decisions, but to my ear it is the word > "triage" that is more about deciding where to allocate resources ("which > release"), whereas we generally don't work that way. We just decide if > it can go in or not, and if the patch is ready before the next release, > it can go in. > > More specifically, because I removed 'committer decision needed', > 'decision needed' covers the case of needing a committer decision, > which is by definition not a triage decision :) > > Perhaps 'committer decision needed' should be kept after all? >From a work queue perspective, two separate states likely makes sense, since "Triage needed" & "Committer decision needed" are aimed at slightly different groups of people (with the latter being a subset of the former). That way, "Committer decision needed" becomes a clear avenue for escalation by triagers to the core developers when they need a design decision or risk assessment on a particular approach. That more structured mechanism should nicely complement the option of punting decisions to the collective wisdom (hah!) of python-dev & python-ideas. Cheers, Nick. > > --David > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Thu May 8 07:44:10 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Thu, 8 May 2014 08:44:10 +0300 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> Message-ID: On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan wrote: > > On 8 May 2014 01:59, "R. David Murray" wrote: >> >> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing >> wrote: >> > I'm wondering if "decision needed" might be more accurately named >> > "triage needed"? >> > >> > Looking at David's well documented proposals and other mail comments, >> > "triage needed" more specifically describes the 'state'. >> > >> > A few thoughts: >> > >> > 1. "Triage needed" would raise the importance and visibility of the >> > triage contributor role. A positive for onboarding and growing >> > development talent. >> > >> > 2. "Triage needed" is more descriptive and clearer than "decision >> > needed" especially for those users that do not read documentation or >> > understand the development workflow. "Decision needed" implies that a >> > decision will be made to include or not include in a release. >> > Realistically, decisions are made throughout the remainder of the >> > development process based on time, resources, etc. >> >> I'll be interested in what others think, but to me "decision needed" is >> closer than "triage needed". That is, the state means that someone other >> than the person moving the issue to that state needs to make a decision. >> That decision can be "Is this something we consider a bug? What releases >> can we fix this in given our backward compatibility requirements? >> Is this an acceptable enhancement? And any other decision that needs >> to be made before the issue can move forward. >> I agree. To me "triaging" mostly means updating fields/metadata and it's something that is done once the issue is reported. This also includes adding people to the nosy list so that they can comment and start dealing with the issues, but I don't consider this "triaging" anymore. IOW "triage needed" would correspond to "- no selection -". OTOH, "decision needed" means that the people working on the issue need to reach an agreement. A good example of this is http://bugs.python.org/issue18967. Here no triaging is needed IMHO. >> All of these *can* be "triage" decisions, but to my ear it is the word >> "triage" that is more about deciding where to allocate resources ("which >> release"), whereas we generally don't work that way. We just decide if >> it can go in or not, and if the patch is ready before the next release, >> it can go in. >> >> More specifically, because I removed 'committer decision needed', >> 'decision needed' covers the case of needing a committer decision, >> which is by definition not a triage decision :) >> >> Perhaps 'committer decision needed' should be kept after all? > I don't think the distinction is useful. Anyone can contribute to the discussion, as long as they don't just give their opinion and change the stage directly. For example in http://bugs.python.org/issue18967 a Mercurial dev could give his opinion, and if the others agree, the stage can be updated (to "needs patch" or "needs review" if a patch is already present). > From a work queue perspective, two separate states likely makes sense, since > "Triage needed" & "Committer decision needed" are aimed at slightly > different groups of people (with the latter being a subset of the former). > That way, "Committer decision needed" becomes a clear avenue for escalation > by triagers to the core developers when they need a design decision or risk > assessment on a particular approach. > I would rather keep the list of stages short, i.e.: - no selection - information needed decision needed patch needed review needed commit (review) needed resolved with the following meanings - no selection -: issue hasn't been triaged/looked at yet information needed: something needs to be confirmed/clarified before proceeding decision needed: an agreement should be reached before taking action patch needed: we know what to do, we need the code review needed: we have the code, we need someone to review it commit (review) needed: we have the code, we need a committer to commit it resolved: issue is now closed These would be useful to (triagers also includes committers): - no selection -: triagers (searching for untriaged issues) information needed: original poster (probably not useful in searches) decision needed: committers (and possibly triagers) patch needed: everyone (people searching for issues that need patches) review needed: triagers (searching for issues that need a review) commit (review) needed: committers (searching for issues that are ready to go in) resolved: everyone (people marveling at the outstanding work of our team) Also think how these stages would affect the dashboards (e.g. "information needed" should be prominent on the original poster's dashboard). To illustrate the possible evolution of an issue I made a couple of flow charts: http://imgur.com/a/UgJBJ The first is without "patch update needed" the second includes it. Also note that is possible to go from basically every state to "resolved", however I omitted those arrows, since they would just clutter the flow chart. I'm not sure if this should be enforced (probably not), but at least it should provided a clearer picture. I left "decision needed", removed "patch update needed", and possibly removed the "review" from "commit review needed": 1) "decision needed" means that the problem is clear, but we have to discuss about the best solution. To me, "triage needed" mostly means that the fields/metadata are not updated; 2) "patch update needed" seems redundant to me, and can be replaced with "patch needed" + "assigned to ". I'm not strongly opposed about removing it though; 3) "commit review needed" seems useful to signal to core devs that someone reviewed the patch and it is now ready to be committed. This assumes that the committer will do a further review, but if we already passed the "review needed" stage, there are good chances that the patch is ready to go in (if not we can always go back to "patch needed"). This can also be simply called "commit needed"; > That more structured mechanism should nicely complement the option of > punting decisions to the collective wisdom (hah!) of python-dev & > python-ideas. > > Cheers, > Nick. > >> >> --David From bcannon at gmail.com Thu May 8 16:31:35 2014 From: bcannon at gmail.com (Brett Cannon) Date: Thu, 08 May 2014 14:31:35 +0000 Subject: [core-workflow] Tracker workflow proposal References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> Message-ID: On Thu May 08 2014 at 1:44:21 AM, Ezio Melotti wrote: > On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan wrote: > > > > On 8 May 2014 01:59, "R. David Murray" wrote: > >> > >> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing > >> wrote: > >> > I'm wondering if "decision needed" might be more accurately named > >> > "triage needed"? > >> > > >> > Looking at David's well documented proposals and other mail comments, > >> > "triage needed" more specifically describes the 'state'. > >> > > >> > A few thoughts: > >> > > >> > 1. "Triage needed" would raise the importance and visibility of the > >> > triage contributor role. A positive for onboarding and growing > >> > development talent. > >> > > >> > 2. "Triage needed" is more descriptive and clearer than "decision > >> > needed" especially for those users that do not read documentation or > >> > understand the development workflow. "Decision needed" implies that a > >> > decision will be made to include or not include in a release. > >> > Realistically, decisions are made throughout the remainder of the > >> > development process based on time, resources, etc. > >> > >> I'll be interested in what others think, but to me "decision needed" is > >> closer than "triage needed". That is, the state means that someone > other > >> than the person moving the issue to that state needs to make a decision. > >> That decision can be "Is this something we consider a bug? What > releases > >> can we fix this in given our backward compatibility requirements? > >> Is this an acceptable enhancement? And any other decision that needs > >> to be made before the issue can move forward. > >> > > I agree. To me "triaging" mostly means updating fields/metadata and > it's something that is done once the issue is reported. This also > includes adding people to the nosy list so that they can comment and > start dealing with the issues, but I don't consider this "triaging" > anymore. IOW "triage needed" would correspond to "- no selection -". > OTOH, "decision needed" means that the people working on the issue > need to reach an agreement. A good example of this is > http://bugs.python.org/issue18967. Here no triaging is needed IMHO. > This is exactly the way I thought as well: the initial default state is "triage needed" and "decision needed" means someone higher up has to make a call on a question. Can we simply name the "no selection" state have the text "triage needed"? -Brett > > >> All of these *can* be "triage" decisions, but to my ear it is the word > >> "triage" that is more about deciding where to allocate resources ("which > >> release"), whereas we generally don't work that way. We just decide if > >> it can go in or not, and if the patch is ready before the next release, > >> it can go in. > >> > >> More specifically, because I removed 'committer decision needed', > >> 'decision needed' covers the case of needing a committer decision, > >> which is by definition not a triage decision :) > >> > >> Perhaps 'committer decision needed' should be kept after all? > > > > I don't think the distinction is useful. Anyone can contribute to the > discussion, as long as they don't just give their opinion and change > the stage directly. For example in http://bugs.python.org/issue18967 > a Mercurial dev could give his opinion, and if the others agree, the > stage can be updated (to "needs patch" or "needs review" if a patch is > already present). > > > From a work queue perspective, two separate states likely makes sense, > since > > "Triage needed" & "Committer decision needed" are aimed at slightly > > different groups of people (with the latter being a subset of the > former). > > That way, "Committer decision needed" becomes a clear avenue for > escalation > > by triagers to the core developers when they need a design decision or > risk > > assessment on a particular approach. > > > > I would rather keep the list of stages short, i.e.: > - no selection - > information needed > decision needed > patch needed > review needed > commit (review) needed > resolved > > with the following meanings > - no selection -: issue hasn't been triaged/looked at yet > information needed: something needs to be confirmed/clarified before > proceeding > decision needed: an agreement should be reached before taking action > patch needed: we know what to do, we need the code > review needed: we have the code, we need someone to review it > commit (review) needed: we have the code, we need a committer to commit > it > resolved: issue is now closed > > These would be useful to (triagers also includes committers): > - no selection -: triagers (searching for untriaged issues) > information needed: original poster (probably not useful in searches) > decision needed: committers (and possibly triagers) > patch needed: everyone (people searching for issues that need patches) > review needed: triagers (searching for issues that need a review) > commit (review) needed: committers (searching for issues that are > ready to go in) > resolved: everyone (people marveling at the outstanding work of our team) > > Also think how these stages would affect the dashboards (e.g. > "information needed" should be prominent on the original poster's > dashboard). > > > To illustrate the possible evolution of an issue I made a couple of flow > charts: > http://imgur.com/a/UgJBJ > > The first is without "patch update needed" the second includes it. > Also note that is possible to go from basically every state to > "resolved", however I omitted those arrows, since they would just > clutter the flow chart. I'm not sure if this should be enforced > (probably not), but at least it should provided a clearer picture. > > I left "decision needed", removed "patch update needed", and possibly > removed the "review" from "commit review needed": > 1) "decision needed" means that the problem is clear, but we have to > discuss about the best solution. To me, "triage needed" mostly means > that the fields/metadata are not updated; > 2) "patch update needed" seems redundant to me, and can be replaced > with "patch needed" + "assigned to ". I'm not > strongly opposed about removing it though; > 3) "commit review needed" seems useful to signal to core devs that > someone reviewed the patch and it is now ready to be committed. This > assumes that the committer will do a further review, but if we already > passed the "review needed" stage, there are good chances that the > patch is ready to go in (if not we can always go back to "patch > needed"). This can also be simply called "commit needed"; > > > > That more structured mechanism should nicely complement the option of > > punting decisions to the collective wisdom (hah!) of python-dev & > > python-ideas. > > > > Cheers, > > Nick. > > > >> > >> --David > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at willingconsulting.com Thu May 8 19:42:45 2014 From: willingc at willingconsulting.com (Carol Willing) Date: Thu, 08 May 2014 10:42:45 -0700 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> Message-ID: <536BC215.1000508@willingconsulting.com> Ezio, Brett, Nick, and David, Your thoughts and additional information added some helpful insights and improvements. Some thoughts in-line below. Here's a link to a document that helps on-board people and demonstrates the many aspects a tracker communicates information to others in the community: https://wiki.openstack.org/wiki/How_To_Contribute [It illustrates fairly concretely that the tracker supports several different workflows and many different community members.] I'm going to go out on a limb and say that we're in agreement on a macro level. FWIW, a few thoughts below on 'state' naming. State ----- "Initial State" (aka No Selection, Triage needed) [I can't think of a great word for this state. What comes to mind is Harry Potter's Sorting Hat to determine where the issue should go] Information Please (aka Information needed) Decision Point (aka decision needed) Patch Development (aka Patch needed) Patch Review Commit Review Resolved > This is exactly the way I thought as well: the initial default state > is "triage needed" IMHO, "triage" has somewhat different connotations to each of us. It's probably best not to use it in the tracker as a state. This would allow documentation to treat "triage" as a process that may differ on the type of task or who is doing the task. My apologies for suggesting it as a state, but it has been interesting seeing the diversity in perspectives of what "triage" means. > and "decision needed" means someone higher up has to make a call on a > question. My apologies in advance if my ability to communicate in writing my next point is below par. Before I say what I am feeling, I want to be clear that I have strong respect for the core developers and committers based on their dedication to and passion for Python. I also have great respect for others that contribute in many different ways and the talents that they bring to a team. I can't quite put my finger on why, but my gut reaction to "decision needed" when coupled with words like "higher ups", "more experienced", "control", "hierarchy", "proven" is unwelcoming and a little patronizing. Oddly, simply stating "decision point" or "decision" as a state does not invoke the same reaction. I think the word "needed" subtly adds the implication that I am not trusted, capable enough, or proven my intelligence to make a decision, and I must wait to get permission from an "authority figure". Not a huge sticking point if consensus wants to keep it as "decision needed". I have actually found folks to be helpful and collaborative. I'm merely throwing my reaction out there because I trust you to consider it. > Can we simply name the "no selection" state have the text "triage needed"? Naming the "no selection" state has merit. Perhaps it auto defaults to the "first step" unless overridden by submitter. > > I would rather keep the list of stages short, i.e.: > Agree that simple is better than complex. > > with the following meanings > - no selection -: issue hasn't been triaged/looked at yet > > information needed: something needs to be confirmed clarified before > proceeding > decision needed: an agreement should be reached before taking action > patch needed: we know what to do, we need the code > review needed: we have the code, we need someone to review it > commit (review) needed: we have the code, we need a committer to > commit it > resolved: issue is now closed > I like these descriptions of the states. > > To illustrate the possible evolution of an issue I made a couple > of flow charts: > http://imgur.com/a/UgJBJ > Thanks for the visuals. They help support understanding the workflow :-) > > Also note that is possible to go from basically every state to > "resolved", however I omitted those arrows, since they would just > clutter the flow chart. > Excellent point. Thanks! Carol P.S. Happy to pitch in with documentation or tracker work as you move forward :-) -- Carol Willing Developer Willing Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezio.melotti at gmail.com Thu May 8 22:59:36 2014 From: ezio.melotti at gmail.com (Ezio Melotti) Date: Thu, 8 May 2014 23:59:36 +0300 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <536BC215.1000508@willingconsulting.com> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> <536BC215.1000508@willingconsulting.com> Message-ID: On Thu, May 8, 2014 at 8:42 PM, Carol Willing wrote: > Ezio, Brett, Nick, and David, > > Your thoughts and additional information added some helpful insights and > improvements. > > Some thoughts in-line below. > > Here's a link to a document that helps on-board people and demonstrates the > many aspects a tracker communicates information to others in the community: > https://wiki.openstack.org/wiki/How_To_Contribute [It illustrates fairly > concretely that the tracker supports several different workflows and many > different community members.] > > I'm going to go out on a limb and say that we're in agreement on a macro > level. FWIW, a few thoughts below on 'state' naming. > > State > ----- > "Initial State" (aka No Selection, Triage > needed) [I can't think of a great word for this state. > What comes to mind is > Harry Potter's Sorting Hat to determine where the issue should go] > Information Please (aka Information needed) > Decision Point (aka decision needed) > Patch Development (aka Patch needed) > Patch Review > Commit Review > Resolved > > This is exactly the way I thought as well: the initial default state is > "triage needed" > > IMHO, "triage" has somewhat different connotations to each of us. It's > probably best not to use it in the tracker as a state. This would allow > documentation to treat "triage" as a process that may differ on the type of > task or who is doing the task. My apologies for suggesting it as a state, > but it has been interesting seeing the diversity in perspectives of what > "triage" means. > FWIW when I started contributing I didn't even know the meaning of the word "triage" (not even in medical context), and I don't think there is any corresponding word in my native language. > and "decision needed" means someone higher up has to make a call on a > question. > > My apologies in advance if my ability to communicate in writing my next > point is below par. Before I say what I am feeling, I want to be clear that > I have strong respect for the core developers and committers based on their > dedication to and passion for Python. I also have great respect for others > that contribute in many different ways and the talents that they bring to a > team. > > I can't quite put my finger on why, but my gut reaction to "decision needed" > when coupled with words like "higher ups", "more experienced", "control", > "hierarchy", "proven" is unwelcoming and a little patronizing. Oddly, simply > stating "decision point" or "decision" as a state does not invoke the same > reaction. I think the word "needed" subtly adds the implication that I am > not trusted, capable enough, or proven my intelligence to make a decision, > and I must wait to get permission from an "authority figure". > Maybe we could use "agreement" or "consensus" (or something equivalent) instead. For simple issues any core dev could take the decision directly (especially if the issue is related to releases or other policies that contributors might not be aware of), but otherwise taking the decision is a group process where anyone can contribute (much like what we are doing here). > Not a huge sticking point if consensus wants to keep it as "decision > needed". I have actually found folks to be helpful and collaborative. I'm > merely throwing my reaction out there because I trust you to consider it. > > Can we simply name the "no selection" state have the text "triage needed"? > > Naming the "no selection" state has merit. Perhaps it auto defaults to the > "first step" unless overridden by submitter. I wonder if only triagers/committers should have the stage field visible while creating a new issue. That would help making sure that, if the stage is different from "no selection", at least a triager looked at the issue. If the field is available to anyone, contributors might set it correctly, but leave other important fields unset, and triagers might end up ignoring the issues because it looks already triaged. >> >> I would rather keep the list of stages short, i.e.: > > Agree that simple is better than complex. > >> with the following meanings >> - no selection -: issue hasn't been triaged/looked at yet >> >> information needed: something needs to be confirmed clarified before >> >> proceeding >> decision needed: an agreement should be reached before taking action >> patch needed: we know what to do, we need the code >> review needed: we have the code, we need someone to review it >> commit (review) needed: we have the code, we need a committer to commit >> it >> resolved: issue is now closed > > I like these descriptions of the states. > >> To illustrate the possible evolution of an issue I made a couple of flow >> charts: >> http://imgur.com/a/UgJBJ > > Thanks for the visuals. They help support understanding the workflow :-) > >> Also note that is possible to go from basically every state to >> "resolved", however I omitted those arrows, since they would just >> clutter the flow chart. > > Excellent point. > > Thanks! > Carol > > P.S. Happy to pitch in with documentation or tracker work as you move > forward :-) > > -- > Carol Willing > Developer > Willing Consulting > From solipsis at pitrou.net Fri May 9 00:05:37 2014 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 9 May 2014 00:05:37 +0200 Subject: [core-workflow] Tracker workflow proposal References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> Message-ID: <20140509000537.21560365@fsol> To everyone participating: the discussion has become IMO completely impossible to follow. There is a single monster-thread discussing all issues at once, without any subject change. I think issues should be broken into distinct threads with distinct mail subjects, to make things readable again. Thanks & regards Antoine. On Thu, 08 May 2014 14:31:35 +0000 Brett Cannon wrote: > On Thu May 08 2014 at 1:44:21 AM, Ezio Melotti > wrote: > > > On Thu, May 8, 2014 at 1:58 AM, Nick Coghlan wrote: > > > > > > On 8 May 2014 01:59, "R. David Murray" wrote: > > >> > > >> On Wed, 07 May 2014 08:09:03 -0700, Carol Willing > > >> wrote: > > >> > I'm wondering if "decision needed" might be more accurately named > > >> > "triage needed"? > > >> > > > >> > Looking at David's well documented proposals and other mail comments, > > >> > "triage needed" more specifically describes the 'state'. > > >> > > > >> > A few thoughts: > > >> > > > >> > 1. "Triage needed" would raise the importance and visibility of the > > >> > triage contributor role. A positive for onboarding and growing > > >> > development talent. > > >> > > > >> > 2. "Triage needed" is more descriptive and clearer than "decision > > >> > needed" especially for those users that do not read documentation or > > >> > understand the development workflow. "Decision needed" implies that a > > >> > decision will be made to include or not include in a release. > > >> > Realistically, decisions are made throughout the remainder of the > > >> > development process based on time, resources, etc. > > >> > > >> I'll be interested in what others think, but to me "decision needed" is > > >> closer than "triage needed". That is, the state means that someone > > other > > >> than the person moving the issue to that state needs to make a decision. > > >> That decision can be "Is this something we consider a bug? What > > releases > > >> can we fix this in given our backward compatibility requirements? > > >> Is this an acceptable enhancement? And any other decision that needs > > >> to be made before the issue can move forward. > > >> > > > > I agree. To me "triaging" mostly means updating fields/metadata and > > it's something that is done once the issue is reported. This also > > includes adding people to the nosy list so that they can comment and > > start dealing with the issues, but I don't consider this "triaging" > > anymore. IOW "triage needed" would correspond to "- no selection -". > > OTOH, "decision needed" means that the people working on the issue > > need to reach an agreement. A good example of this is > > http://bugs.python.org/issue18967. Here no triaging is needed IMHO. > > > > This is exactly the way I thought as well: the initial default state is > "triage needed" and "decision needed" means someone higher up has to make a > call on a question. Can we simply name the "no selection" state have the > text "triage needed"? > > -Brett > > > > > > >> All of these *can* be "triage" decisions, but to my ear it is the word > > >> "triage" that is more about deciding where to allocate resources ("which > > >> release"), whereas we generally don't work that way. We just decide if > > >> it can go in or not, and if the patch is ready before the next release, > > >> it can go in. > > >> > > >> More specifically, because I removed 'committer decision needed', > > >> 'decision needed' covers the case of needing a committer decision, > > >> which is by definition not a triage decision :) > > >> > > >> Perhaps 'committer decision needed' should be kept after all? > > > > > > > I don't think the distinction is useful. Anyone can contribute to the > > discussion, as long as they don't just give their opinion and change > > the stage directly. For example in http://bugs.python.org/issue18967 > > a Mercurial dev could give his opinion, and if the others agree, the > > stage can be updated (to "needs patch" or "needs review" if a patch is > > already present). > > > > > From a work queue perspective, two separate states likely makes sense, > > since > > > "Triage needed" & "Committer decision needed" are aimed at slightly > > > different groups of people (with the latter being a subset of the > > former). > > > That way, "Committer decision needed" becomes a clear avenue for > > escalation > > > by triagers to the core developers when they need a design decision or > > risk > > > assessment on a particular approach. > > > > > > > I would rather keep the list of stages short, i.e.: > > - no selection - > > information needed > > decision needed > > patch needed > > review needed > > commit (review) needed > > resolved > > > > with the following meanings > > - no selection -: issue hasn't been triaged/looked at yet > > information needed: something needs to be confirmed/clarified before > > proceeding > > decision needed: an agreement should be reached before taking action > > patch needed: we know what to do, we need the code > > review needed: we have the code, we need someone to review it > > commit (review) needed: we have the code, we need a committer to commit > > it > > resolved: issue is now closed > > > > These would be useful to (triagers also includes committers): > > - no selection -: triagers (searching for untriaged issues) > > information needed: original poster (probably not useful in searches) > > decision needed: committers (and possibly triagers) > > patch needed: everyone (people searching for issues that need patches) > > review needed: triagers (searching for issues that need a review) > > commit (review) needed: committers (searching for issues that are > > ready to go in) > > resolved: everyone (people marveling at the outstanding work of our team) > > > > Also think how these stages would affect the dashboards (e.g. > > "information needed" should be prominent on the original poster's > > dashboard). > > > > > > To illustrate the possible evolution of an issue I made a couple of flow > > charts: > > http://imgur.com/a/UgJBJ > > > > The first is without "patch update needed" the second includes it. > > Also note that is possible to go from basically every state to > > "resolved", however I omitted those arrows, since they would just > > clutter the flow chart. I'm not sure if this should be enforced > > (probably not), but at least it should provided a clearer picture. > > > > I left "decision needed", removed "patch update needed", and possibly > > removed the "review" from "commit review needed": > > 1) "decision needed" means that the problem is clear, but we have to > > discuss about the best solution. To me, "triage needed" mostly means > > that the fields/metadata are not updated; > > 2) "patch update needed" seems redundant to me, and can be replaced > > with "patch needed" + "assigned to ". I'm not > > strongly opposed about removing it though; > > 3) "commit review needed" seems useful to signal to core devs that > > someone reviewed the patch and it is now ready to be committed. This > > assumes that the committer will do a further review, but if we already > > passed the "review needed" stage, there are good chances that the > > patch is ready to go in (if not we can always go back to "patch > > needed"). This can also be simply called "commit needed"; > > > > > > > That more structured mechanism should nicely complement the option of > > > punting decisions to the collective wisdom (hah!) of python-dev & > > > python-ideas. > > > > > > Cheers, > > > Nick. > > > > > >> > > >> --David > > _______________________________________________ > > 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 > > > From ncoghlan at gmail.com Fri May 9 00:07:23 2014 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 9 May 2014 08:07:23 +1000 Subject: [core-workflow] Tracker workflow proposal In-Reply-To: <536BC215.1000508@willingconsulting.com> References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> <536BC215.1000508@willingconsulting.com> Message-ID: On 9 May 2014 04:32, "Carol Willing" wrote: > >> and "decision needed" means someone higher up has to make a call on a question. > > My apologies in advance if my ability to communicate in writing my next point is below par. Before I say what I am feeling, I want to be clear that I have strong respect for the core developers and committers based on their dedication to and passion for Python. I also have great respect for others that contribute in many different ways and the talents that they bring to a team. > > I can't quite put my finger on why, but my gut reaction to "decision needed" when coupled with words like "higher ups", "more experienced", "control", "hierarchy", "proven" is unwelcoming and a little patronizing. Oddly, simply stating "decision point" or "decision" as a state does not invoke the same reaction. I think the word "needed" subtly adds the implication that I am not trusted, capable enough, or proven my intelligence to make a decision, and I must wait to get permission from an "authority figure". > > Not a huge sticking point if consensus wants to keep it as "decision needed". I have actually found folks to be helpful and collaborative. I'm merely throwing my reaction out there because I trust you to consider it. "Consensus/decision needed" may be a more accurate name for the state - an autocratic decision from a core developer or module maintainer is a last resort to get an issue moving again, rather than the preferred approach. "Rough consensus and running code" (or "readable text" in the docs case) is a much better option when it works, but that can occasionally stall with no way to move forward (or, worse, descend into bitter acrimony over a potentially trivial issue) in the absence of an escalation procedure of some kind. So core devs (& particularly module maintainers) really do have decision making authority. I don't think we'd be doing anyone any favours by pretending that hierarchy doesn't exist instead of trying to make it as transparent as possible - including the fact that gaining more responsibility (for those that want it) is mostly a case of "the reward for doing work well is being offered the chance to do more work". On the other hand, Ezio's also right that our decision making authority is essentially limited getting to define how rough "rough consensus" can be in any given situation, and even if a core dev or module maintainer is needed to make the final call, we're often in the situation of catching up on a discussion that may have been going on for a while (see the couple of paragraphs in http://www.joelonsoftware.com/articles/fog0000000072.htmlthat start with "At Microsoft, management was extremely hands-off.") In those cases, *anyone* can take it upon themselves to: * write a comment on the issue tracker summarising the competing perspectives and their pros and cons * escalating the issue to python-dev for broader discussion (preferably with a summary like the one above) * for more radical/controversial notions, start a thread on python-ideas to request help in building a compelling case for the proposal Sometimes those acts will allow consensus to emerge without an explicit decision being needed from anyone. Cheers, Nick. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at willingconsulting.com Fri May 9 02:49:11 2014 From: willingc at willingconsulting.com (Carol Willing) Date: Thu, 08 May 2014 17:49:11 -0700 Subject: [core-workflow] [Sub_Issue: State Naming re: Decisions] Tracker workflow proposal In-Reply-To: References: <20140421160435.35094250CAE@webabinitio.net> <535900B0.1070504@email.de> <20140424165411.42116250D5C@webabinitio.net> <53597CE1.8070406@email.de> <20140424212305.1C557250D5D@webabinitio.net> <20140505152448.5DD2D250D4E@webabinitio.net> <536A4C8F.3050606@willingconsulting.com> <20140507155929.D2AA6250D68@webabinitio.net> <536BC215.1000508@willingconsulting.com> Message-ID: <536C2607.3000708@willingconsulting.com> Nick and Ezio, Thanks! We're in sync. I appreciate your thoughtful responses regarding the state label "decision needed". I'm +1 on transparency and clarity around consensus building and do not disagree with "final decision" authority rests with the module maintainer or core dev which is far better than languishing issues. I believe it would be helpful for some of Nick and Ezio's thoughts making it into some documentation (dev guide?): "...an autocratic decision from a core developer or module maintainer is a last resort to get an issue moving again, rather than the preferred approach...decision making authority is essentially limited getting to define how rough "rough consensus" can be in any given situation, and even if a core dev or module maintainer is needed to make the final call, we're often in the situation of catching up on a discussion that may have been going on for a while." Any of these names (Green light needed, consensus/decision needed, or decision needed) will work well when combined with greater community education (via docs and other communication mechanisms). Hopefully, this upfront dialogue will help the workflow tracker enable more people to contribute most effectively and in turn will reward core devs with more "meaningful" work not just more work. Regards, Carol P.S. Antoine, Point taken. If anyone is aware of a dynamic mailing list message "diff" organizer other than brute force, I would love to know. Cheers! On 5/8/14, 3:07 PM, Nick Coghlan wrote: > > > On 9 May 2014 04:32, "Carol Willing" > wrote: > > > >> and "decision needed" means someone higher up has to make a call on > a question. > > > > My apologies in advance if my ability to communicate in writing my > next point is below par. Before I say what I am feeling, I want to be > clear that I have strong respect for the core developers and > committers based on their dedication to and passion for Python. I also > have great respect for others that contribute in many different ways > and the talents that they bring to a team. > > > > I can't quite put my finger on why, but my gut reaction to "decision > needed" when coupled with words like "higher ups", "more experienced", > "control", "hierarchy", "proven" is unwelcoming and a little > patronizing. Oddly, simply stating "decision point" or "decision" as a > state does not invoke the same reaction. I think the word "needed" > subtly adds the implication that I am not trusted, capable enough, or > proven my intelligence to make a decision, and I must wait to get > permission from an "authority figure". > > > > Not a huge sticking point if consensus wants to keep it as "decision > needed". I have actually found folks to be helpful and collaborative. > I'm merely throwing my reaction out there because I trust you to > consider it. > > "Consensus/decision needed" may be a more accurate name for the state > - an autocratic decision from a core developer or module maintainer is > a last resort to get an issue moving again, rather than the preferred > approach. "Rough consensus and running code" (or "readable text" in > the docs case) is a much better option when it works, but that can > occasionally stall with no way to move forward (or, worse, descend > into bitter acrimony over a potentially trivial issue) in the absence > of an escalation procedure of some kind. > > So core devs (& particularly module maintainers) really do have > decision making authority. I don't think we'd be doing anyone any > favours by pretending that hierarchy doesn't exist instead of trying > to make it as transparent as possible - including the fact that > gaining more responsibility (for those that want it) is mostly a case > of "the reward for doing work well is being offered the chance to do > more work". > > On the other hand, Ezio's also right that our decision making > authority is essentially limited getting to define how rough "rough > consensus" can be in any given situation, and even if a core dev or > module maintainer is needed to make the final call, we're often in the > situation of catching up on a discussion that may have been going on > for a while (see the couple of paragraphs in > http://www.joelonsoftware.com/articles/fog0000000072.html that start > with "At Microsoft, management was extremely hands-off.") > > In those cases, *anyone* can take it upon themselves to: > > * write a comment on the issue tracker summarising the competing > perspectives and their pros and cons > * escalating the issue to python-dev for broader discussion > (preferably with a summary like the one above) > * for more radical/controversial notions, start a thread on > python-ideas to request help in building a compelling case for the > proposal > > Sometimes those acts will allow consensus to emerge without an > explicit decision being needed from anyone. > > Cheers, > Nick. > -- Carol Willing Developer Willing Consulting -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Thu May 15 11:09:18 2014 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 15 May 2014 12:09:18 +0300 Subject: [core-workflow] workflow types: agile (gameplay) vs rigid (process) In-Reply-To: References: Message-ID: On Thu, May 1, 2014 at 11:21 AM, Tal Einat wrote: > > First of all, your post is off-topic for this list. We are here to > discuss the workflow of core Python development and related tools, not > to have general discussions about workflow. It is the same as saying "We are here to discuss the structure of objects of our program, not to have general discussions about classes". Don't you think that discussing structure of objects without touching classes is a little bit weird? You do realize that everybody should know at least what kind of possibilities are available. > Next, using a title such as "agile (gameplay) vs rigid (process)" is > inflammatory (= will make people angry) but uninformative and > unhelpful. We are speaking about some imaginary angry people or it made you angry? If it is so - say it to me. I don't understand why it makes you angry and I won't if you don't tell me. You can use private email. About being uninformative - I am waiting for questions. And note - it's not me who is starting offtopic. > Furthermore, to the extent of my understanding of the relevant terms, > you show a complete misunderstanding of them. Here are some specific > examples: > >> Agile workflows often take into account >> personalities, habits and environment of people >> involved in a process. > > I have never encountered a workflow which specifically takes into > account personalities and habits. In my opinion it is silly to say > that agile workflows take personalities and habits into account while > other workflows do not. It is said that agile workflows often take personalities and habits into account. Not that all agile workflows do this. If you take personalities and habits into account and adjust your workflow accordingly, then it is flexible. If this workflow can also adapt to other factors dynamically - it can be named agile (usually "agile" means that your workflow is a combination of well-known patterns that are combined - kanban, iterations, backlog, othergameplayhere, etc.). It will help to understand it better if you compare it to usual corporate workflow, where you have a "position" and a set strict actions that this position can do and what responsibilities it has. This is not adjustable, so it is a rigid workflow. Workflows also have an indicators that they are rigid. If there is a formal paper that regulates interactions, then there workflow is most likely rigid (hard to change). > On the other hand, regardless of workflow, any specific development > group should take into account many considerations, including the > environment and its members' personalities and habits. This has > nothing to do with workflow, so I simply cannot make any sense of your > above statement. Yes, it seems obvious that every development group naturally tries to take into account many considerations, including environment, but in parts of the world where most outsourcing takes place you often can not adapt environment - the environment filters and forges people. Many just leave. In remote teams you need to be extra careful about people and bus factor. Many competencies are unique and you don't have a community of developers on your project to filter from. >> Just think about why different people don't feel fun >> contributing to Python overall, who are those people, >> why Python community needs them, and how you >> can help them by removing obstacles. > > This is precisely what the Python developers and the PSF have always > done. Specifically, in recent years they have been spending more and > more time and effort on this. Despite this you have repeatedly (now > and in the past) accused them all of not doing so, and you are simply > completely *wrong*. This just shows how distorted your view of the > Python developers is. I never said that PSF doesn't do anything at all. My main criticism is that what it does is insufficient, lacks visibility, does not have a feedback loop, and as a result - not effective. FWIW, I don't like that PSF protects legalese instead of defending open source values, it doesn't invest in researching and solving conflicts, can't set focus for community, organize collaboration and open environment for hacking, learning and cross-disciplinary exchange. I am saying it here, because PSF is major factor that affects people minds and as a result, evolution of workflow tools. Some people don't participate, because there is an organization that exists to solve problems. The hope that if somebody is active in doing something, this organization works with them in reaching their goals, help them, not limit them, ignore or ban. If there is an opinion, this organization counts that opinion, makes stats, provides something that this person can not provide. PSF is made for legalese. I asked many times to provide a short hacker's guide on CLA - why it exists, why the wording is like this, what every word means, why these specific words are there, what countries are affected, why some clauses don't work by default and what needs to be changed to make open source a better place like it was before. Legalese if the primary function of PSF as I see it. Does anybody who can help to answer these questions tried to contact me? No. What is the PSF workflow? How does it know that it does anything right? >> workflow types: agile (gameplay) vs rigid (process) > > This is ridiculous. Every agile methodology I have heard of includes > some specific process for development. From all of the development > groups I have been in or worked with, those which used "agile" methods > had much clearer processes which they actually stuck to and which were > usually more effective. "Agile" does not mean not taking work > seriously and it is not an excuse for lack of process. There is nothing contradictory with what you say. I completely support this. It is confusing use of parentheses on my side. Title undergo an evolution to become more clear, but final mutation changed meaning: -> agile vs rigid workflows (there are people who don't know about agile or who think that agile is another buzzword) -> workflows: agile vs rigid (still there is no definition what is "agile" and what is "rigid", and I am the one to educate or coin one) -> workflows: agile gameplay vs rigid process (it is not about gameplay vs process, so accent should be on being flexible and not try to make PEP that will filter people) -> workflows: agile (gameplay) vs rigid (process) > Perhaps you have met some developers who used "agile" as an excuse for > not defining processes, but you would be wrong to think this is true > of all other groups who use "agile" methods. Now it is crystal clear that "agile process" is also process, and the main difference from "rigid process" is that "agile" process includes a mechanism for changing itself as soon as it is necessary. > To summarize, this post is off-topic, inflammatory and contains > several grossly incorrect statements. In my opinion this discussion > should not continue here. Do you still think so? -- anatoly t. From taleinat at gmail.com Thu May 15 20:35:11 2014 From: taleinat at gmail.com (Tal Einat) Date: Thu, 15 May 2014 21:35:11 +0300 Subject: [core-workflow] workflow types: agile (gameplay) vs rigid (process) In-Reply-To: References: Message-ID: Hi Anatoly, This is getting long and very "meta", but I feel I must reply and explain further so that there is a chance that useful discussion can later happen in this forum. One important member has already said that he is considering leaving in light of your post, so obviously some action is required to save this forum, and I choose to do so openly and in the relevant context. I do ask that if you have any specific points you'd like to clear up on this subject, please let's discuss them privately before bringing them to everyone's attention. To everyone else, this here so that you can read it if you like, and for future reference. On Thu, May 15, 2014 at 12:09 PM, anatoly techtonik wrote: > On Thu, May 1, 2014 at 11:21 AM, Tal Einat wrote: >> >> First of all, your post is off-topic for this list. We are here to >> discuss the workflow of core Python development and related tools, not >> to have general discussions about workflow. > > It is the same as saying "We are here to discuss the structure of objects > of our program, not to have general discussions about classes". > > Don't you think that discussing structure of objects without touching > classes is a little bit weird? You do realize that everybody should know > at least what kind of possibilities are available. Are general discussions about OOP are relevant on python-list? Despite Python being a programming language, they *are not relevant* unless they are somehow *directly* related to Python. A discussion about whether "agile" or "rigid" workflows would be better suited *for core Python* could be relevant on this list. In such a context, giving references to relevant sources of background info could be useful. However, starting a *general* discussion about types of workflows is not *directly* relevant. I am not saying that it could not possibly be useful to discuss here, but there was no previous discussion in whose context it became useful and relevant *now*. To phrase the above differently, the discussion here should assume that common concepts are understood by the participants. If someone doesn't know a concept, they can ask or do their own research. If, during a *directly relevant* discussion, there is a reason to make sure that the concepts are understood to mean the same thing by everyone, that would be a different matter. Even in such a case, though, a few pointers to good reading sources should be the start, and discussion should only arise if there is disagreement with those sources. That is usually quite rare. >> Next, using a title such as "agile (gameplay) vs rigid (process)" is >> inflammatory (= will make people angry) but uninformative and >> unhelpful. > > We are speaking about some imaginary angry people or it made you > angry? If it is so - say it to me. I don't understand why it makes you > angry and I won't if you don't tell me. You can use private email. I am not angry at all. From previous experience from posts with such subjects, I have learned that they tend to cause tension and anger. A remark can be inflammatory even if it does not succeed in making anyone angry. For example, "vim rules, Emacs sucks" is a subject which may cause heated debate -- it is inflammatory because that it what it tries to achieve. This can be true even if the author didn't mean for it to be inflammatory. > About being uninformative - I am waiting for questions. And note - it's > not me who is starting offtopic. Uninformative does not mean I need more information. It means that you wrote something which does not convey much information. Your subject is like "virtue: good (north) vs. evil (south)" -- not much information in there, and also confusing and mixing up unrelated concepts. I do insist that "gameplay" and "process" are confusing and out of place in your subject. I've done "classic" work planning with "games" and I've done "agile" without them. And both "agile" and "rigid" are different kinds of processes, so calling one of them "process" is a mistake. >> Furthermore, to the extent of my understanding of the relevant terms, >> you show a complete misunderstanding of them. Here are some specific >> examples: >> >>> Agile workflows often take into account >>> personalities, habits and environment of people >>> involved in a process. >> >> I have never encountered a workflow which specifically takes into >> account personalities and habits. In my opinion it is silly to say >> that agile workflows take personalities and habits into account while >> other workflows do not. > > It is said that agile workflows often take personalities and habits into > account. Not that all agile workflows do this. If you take personalities > and habits into account and adjust your workflow accordingly, then it > is flexible. If this workflow can also adapt to other factors dynamically > - it can be named agile (usually "agile" means that your workflow is a > combination of well-known patterns that are combined - kanban, > iterations, backlog, othergameplayhere, etc.). And here is the source of the problem -- "agile" is not a very well defined term, and different people understand it differently. From my understanding, "agile" is not about combining several patterns from a pool of well-known ones such as Kanban or "planning poker". And even if that is your understanding of the term, that has nothing to do with the personalities of the people involved. > It will help to understand it better if you compare it to usual corporate > workflow, where you have a "position" and a set strict actions that this > position can do and what responsibilities it has. This is not adjustable, > so it is a rigid workflow. "Corporate workflow" can be just as adjustable as "agile". I've seen teams do "agile" without changing their process over time. On the other hand, I've seem teams do "classic" development but adjust their positions, responsibilities and processes very often. Whether the workflow is adjusted over time, and how often this happens, is unrelated to whether this workflow is considered "agile". "Agile" usually means that the work plan is flexible -- not the process itself! The plan is changed often to meet changing requirements, customers or other needs and limitations. Even in "agile", the process by which the work plan is created and changed can stay the same or be changed over time, but that is a different matter. > Workflows also have an indicators that they are rigid. If there is a > formal paper that regulates interactions, then there workflow is most > likely rigid (hard to change). No, that means that the process is rigid. I can write a formal paper describing the different roles and interactions for SCRUMM (an "agile" methodology), enforce those in an organization, and have as a result an "agile" workflow with a rigid, highly-specified process. >> On the other hand, regardless of workflow, any specific development >> group should take into account many considerations, including the >> environment and its members' personalities and habits. This has >> nothing to do with workflow, so I simply cannot make any sense of your >> above statement. > > Yes, it seems obvious that every development group naturally tries to > take into account many considerations, including environment, but in > parts of the world where most outsourcing takes place you often > can not adapt environment - the environment filters and forges people. > Many just leave. In remote teams you need to be extra careful about > people and bus factor. Many competencies are unique and you don't > have a community of developers on your project to filter from. I read that several times but can't quite understand what your point is. If the available personnel and their competencies are limited, that is just one factor that should be taken into account when planning work or defining processes. If you need to be careful not to drive away potential contributors, that is another such factor. This last is something you've been mentioning often so I'm guessing it is at least part of what you're trying to say. And still I don't see how "agile" or "rigid" has anything to do with this. For anyone still reading: The following part is about Anatoly's personal feelings about and experience with the PSF. There is nothing remotely related to workflow issues. >>> Just think about why different people don't feel fun >>> contributing to Python overall, who are those people, >>> why Python community needs them, and how you >>> can help them by removing obstacles. >> >> This is precisely what the Python developers and the PSF have always >> done. Specifically, in recent years they have been spending more and >> more time and effort on this. Despite this you have repeatedly (now >> and in the past) accused them all of not doing so, and you are simply >> completely *wrong*. This just shows how distorted your view of the >> Python developers is. > > I never said that PSF doesn't do anything at all. My main criticism is that > what it does is insufficient, lacks visibility, does not have a feedback loop, > and as a result - not effective. FWIW, I don't like that PSF protects > legalese instead of defending open source values, it doesn't invest in > researching and solving conflicts, can't set focus for community, organize > collaboration and open environment for hacking, learning and > cross-disciplinary exchange. What you personally don't like about the PSF really isn't relevant here. > I am saying it here, because PSF is major factor that affects people > minds and as a result, evolution of workflow tools. Some people don't > participate, because there is an organization that exists to solve problems. > The hope that if somebody is active in doing something, this organization > works with them in reaching their goals, help them, not limit them, ignore > or ban. If there is an opinion, this organization counts that opinion, makes > stats, provides something that this person can not provide. The PSF's effect on the workflow is very indirect, especially as you describe it. To claim that such indirect influence is reason to voice your opinions of the PSF here is just an excuse. As is obvious, the PSF is not dictating any process or workflow, and is hardly taking part in the discussion as far as I can tell. This is all being left to us, the community of developers. So leave the PSF out of this discussion -- it isn't relevant. > PSF is made for legalese. I asked many times to provide a short hacker's > guide on CLA - why it exists, why the wording is like this, what every word > means, why these specific words are there, what countries are affected, > why some clauses don't work by default and what needs to be changed to > make open source a better place like it was before. Come on, really? "a short hacker's guide" ... "what every word means"?! Your requests are not being granted simply because they are not reasonable. > Legalese if the primary > function of PSF as I see it. Does anybody who can help to answer these > questions tried to contact me? No. Several such people have contacted you and tried to help you understand these things. It is very annoying that you say that they have not! They have invested more time and effort with you than they should have and you ignore that completely. Your lack of respect towards them is outrageous. > What is the PSF workflow? How does it know that it does anything right? How can anyone ever know that she is doing something "right"?. There usually isn't any "right" way to do things. Your argument has no merit. >>> workflow types: agile (gameplay) vs rigid (process) >> >> This is ridiculous. Every agile methodology I have heard of includes >> some specific process for development. From all of the development >> groups I have been in or worked with, those which used "agile" methods >> had much clearer processes which they actually stuck to and which were >> usually more effective. "Agile" does not mean not taking work >> seriously and it is not an excuse for lack of process. > > There is nothing contradictory with what you say. I completely support > this. It is confusing use of parentheses on my side. Title undergo an > evolution to become more clear, but final mutation changed meaning: > -> agile vs rigid workflows > (there are people who don't know about agile or who think that agile > is another buzzword) > -> workflows: agile vs rigid > (still there is no definition what is "agile" and what is "rigid", and I am > the one to educate or coin one) > -> workflows: agile gameplay vs rigid process > (it is not about gameplay vs process, so accent should be on being > flexible and not try to make PEP that will filter people) > -> workflows: agile (gameplay) vs rigid (process) Regardless of how you came to it, the subject you chose is terrible. I've already gone into detail about this above. >> Perhaps you have met some developers who used "agile" as an excuse for >> not defining processes, but you would be wrong to think this is true >> of all other groups who use "agile" methods. > > Now it is crystal clear that "agile process" is also process, and the > main difference from "rigid process" is that "agile" process includes > a mechanism for changing itself as soon as it is necessary. Perhaps some processes do this, but not all. As I've explained above, "agile" is usually taken to mean that the work plan is flexible, not the process itself. It is natural that people who choose a flexible work plan as a solution to quickly changing requirements and needs will sometimes also be flexible with their process as well. Still, you should not confuse the flexibility of process by which work is done with the flexibility of what is done using that process. >> To summarize, this post is off-topic, inflammatory and contains >> several grossly incorrect statements. In my opinion this discussion >> should not continue here. > > Do you still think so? Absolutely. As I mentioned in the beginning, please take up any additional related points with me privately. This discussion must not continue here. - Tal