
Yet another idea that some of you will find strange. It is a parallel Python development process. It doesn't affect or replace current practice, so nobody gets hurt. It is also about open process, where openness means transparency (eliminate hidden communication), inclusiveness (eliminate exclusive rights and privileges) and accessibility (eliminate awkward practices and poor user experience). The idea is to split development of Python into two weeks cycle. Every two weeks is "iteration". Iteration consists of phases: 1. Planning (one, two days) 2. Execution 3. Testing 4. Demo 5. Retrospective Some of you, who familiar with concept of "sprint" and know something about "agile" buzzwords will find this idea familiar. In fact, this is borrowed from some of the best practices of working with remote teams who use this methodology. (Planning) So, during these the first, planning phase, people, who'd like to participate - choose what should be implemented in this iteration. For that there should be a list of things to be done. This list is called "backlog". People collaboratively estimate complexity and sort the things by priority. (Execution) You take a thing from backlog, mark that you're working on it, so that other people who are also interested can find you. If you need help, you split the thing into subtasks and make these tasks open for people to find and jump in. (Testing) This is a phase when work done is compared with actual thing description. Sometimes this leads to new insights, new ideas, new bugs and more work to be done in subsequent iteration. Sometimes it appears that during execution the thing completely diverged from what was originally planned. (Demo) Demonstration of the things done. Record progress, give credits and close mark things in backlog as done. Demo is made for broader community that just for a list of participants. (Retrospective) This is an important phase that is dedicated to gathering and processing feedback to improve the iteration loop. Every person reports what he/she liked and disliked, what was the % of overall fun. Then some things and ideas are being born from the feedback - what can be improved - being it tools, interaction with people or some other things that get in the way. -- anatoly t.

On 01/28/2014 11:44 PM, anatoly techtonik wrote:
It is a parallel Python development process. It doesn't affect or replace current practice, so nobody gets hurt.
So you're saying that we would have the current model, plus this agile model?
What "hidden" communication? Talking in person or on IRC? Instead of ... where?
inclusiveness (eliminate exclusive rights and privileges)
Exclusive rights? You mean let any piece of code get committed?
and accessibility (eliminate awkward practices and poor user experience).
It is not possible to please everyone; it is also not possible to ensure a "good user experience" for everyone.
The idea is to split development of Python into two weeks cycle.
80 hours? Do you have any idea how long it takes some of us to put in 80 hours of Python development time? -- ~Ethan~

On Wed, Jan 29, 2014 at 11:29 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I am saying that you're not forced to follow agile model if you don't like it. You can do what you do as you did before.
If information doesn't reach the recipient who want to read it, it is "hidden". Even if you talk in public channel on IRC, the information is hidden from me if I was not connected and channel doesn't have public logs.
inclusiveness (eliminate exclusive rights and privileges) Exclusive rights? You mean let any piece of code get committed?
There are many exclusive rights that keep people off from contributing. I don't want to touch them here, because it will move the thread into different area. To make it more specific "inclusiveness" on the process is the process too. You start with people who have full exclusive rights and contributing then compare them to people who are willing to help, but don't do this. Then you remove the obstacles to include these people.
That's a general claim. I am sure that it is possible to reach the point where everyone agree that their experience is "good enough user experience". And there is a dedicated time in the process (retrospective) to work on just on that.
It is not development time. These two weeks cycle is just ordinary time, which may include 15 minutes of development time, a week or nothing. It is up to you - how much are you willing to spend.

On Wed, Jan 29, 2014 at 11:29 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Then if you care, connect. It's not hidden if you have the power to access it. Here's a suggestion: Fork Python (that's legal, that's what open source means) and start development using the model you advocate. If it's massively better than what's happening, (a) developers will flock to your model, and (b) the project could be completely handed over to you, as happened with GCC. Or alternatively, explain to us here what the real advantages are of your new model. So far, what I've seen is "hey, here's an idea", and not "here's what this idea will do to benefit Python"; and the idea itself looks more suited to a big business than to open source. Maybe someone who's actually used Agile will know what's so wonderful about it, but unless every core dev *has*, a bit of explanation will help. ChrisA

On 29 January 2014 23:57, Chris Angelico <rosuav@gmail.com> wrote:
Plenty of us have used it, and we know it's an entirely inappropriate model for open source development projects with broad asynchronous participation, as the time commitment needed to make the short cycle work is antithetical to loose collaboration. It works well for a focused team supporting a single application to meet the specific needs of a single business, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Jan 29, 2014 at 5:18 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
About *Agile* I tried to avoid the word Agile, but since you saying that you've used that, let us agree on terminology. In my world *agile* means *flexible*, which means *able to change*. It doesn't mean *scrum* or *two weeks sprint* or any of the hardcoded value that you put behind the phrase of "entirely inappropriate model for open source". Not that that's clear, let's move on. "Asynchronous participation" is called "distributed development", and it is used both by open source and by commercial companies a lot. If Yahoo terminated this practice and Google didn't even try - that's a problem of management of these companies. It doesn't mean it doesn't work for professional teams or people *interested* in interacting this way. Agile helps to analyze and improve distributed development processes the same way it does for rigid corporate practices. You say - "short cycles" are bad. In agile I'd say - let's try and see why. Maybe it's cycles what are bad, maybe it's people who can not sync this often, maybe there is a technical problem with communication that can be resolved by using right tools.

On Thu, Jan 30, 2014 at 10:56 PM, anatoly techtonik <techtonik@gmail.com> wrote:
The very concept of a cycle suggests a system that's more suited to a business environment than general open source development. Forcing people to pick up and set down work might be useful in the very short period just before a version release (I've been seeing some stuff about Argument Clinic - btw, kudos to the tireless people doing that, it's a huge job - and how some of the work will be deferred to 3.5), but most of the time, it's completely unnecessary. In big business, you might have a couple dozen programmers working on some particular job; in that two week cycle, each one could potentially put in quite a few hours. I heard a figure of 80 hours quoted, but I'm dubious about how many actual dev hours a salaried programmer would get done, in between meetings and whatnot. Still, could easily be upwards of 50 hours. Forcing everyone to stop and re-check things every fifty dev hours doesn't sound too bad. Now look at volunteers. Two weeks might be anywhere from zero hours up to... well, the upper end doesn't matter. But it could easily be just a single dev hour in that time. Are you then going to force this person to set aside what he's partially done, because of some arbitrary break point? Now, what happens if you take Agile and eliminate the two-week period? It begins to look very much like a pool of issues on a bug tracker. You have a pile of stuff to do, someone picks up something he feels like doing, posts a result back. Hmm, I wonder if that might be what's already happening... Do you see now why I was, without any experience of Agile, already dubious about its merits? And that even before Nick stated from experience that it's not going to help. Ideas are all very well, but they're useless without some form of test-bed. The only perfect way to find out if an idea works or not is to try it, and the onus is on the inventor to risk something for his idea. Put the theory to work on some project. Once you can point to some clear advantages *in practice*, you'll be able to recommend this to other people. So... fork CPython, tell us all how wonderful your version is going to be, and then show us how, in two weeks, or four weeks, or six weeks, you can do amazing stuff with a motley crew of programmers. Then we'll all take notice. ChrisA

On Thu, Jan 30, 2014 at 3:49 PM, Chris Angelico <rosuav@gmail.com> wrote:
The cycle is needed when you need some kind of visibility in the process. For business environment it is critical, because it has to control the spendings. For open source environment it is critical for people, because they need to plan their time.
Again, it is not forcing anyone. It is just a process. You are free to fail you development goal. It is not a business - there is nobody to fire you or say that you're underperforming. There is no heroism either. If you do not know your development pace, you can try and measure it, if you do know, you just realistically state what are you working on and if you need help with that.
Single dev hour is ok if you reached your goal. That's the point. You set the goals - you reach them. If you didn't reach them - you analyze and see what could be done better. It is all in relaxing and free manner, unlike the bloody corporation culture. You may invite other people to join the fun. People can find what are you working on and propose help. This is the process.
That's a crowdsourced development, not a team work in distributed environment. And there is no place for team to appear if everybody looks at a big pile of garbage and chooses the shiny metal plate that is precious only yo him. The environment you've described is not encouraging team birth and collaboration in any way. More than that - it looks like people would even oppose if commercial development teams would propose their work. In the past it happened already with "unladen swallow" project. Current development process couldn't munch the result if this work, and people didn't even try to adjust the process to make the future efforts possible.
I don't want core devs to accept this process at all. I don't want to sell it to them and I don't want them to follow it. =) It is completely optional, and I just don't want them to make more obstacles to new people who would like to try these. It may happen that resistance to change for open source projects may be bigger than in organizations. I just want to make sure that people aware that applying agile methodology to open source development is possible and I am inclined that it brings more positive improvements for the Python itself than de-facto development processes.

On Fri, Jan 31, 2014 at 12:25 AM, anatoly techtonik <techtonik@gmail.com> wrote:
Let's say you pick up something that's going to turn out to take you three dev hours. You then put one hour of work into it, and the two-week cut-off rolls around. What do you do? In the current model, there is no cut-off, so you just keep your work where it is until you find the time to finish it. Then you format it as a patch, put it on the tracker issue, and move on. (Or, if you're a core dev, I suppose you push it, see if the buildbots start looking red and angry, and then move on. Either way.) It doesn't matter if that took you one day, two weeks, or three months. What you're suggesting is that people should conform to an arbitrary number-of-days cutoff. That means that if the cut-off is getting close, there's a *dis*incentive to pick up any job, because you won't be able to finish it. Imagine if, when writing up a post for the mailing list, you had to finish each sentence inside one minute as per the clock. If it's currently showing hh:mm:49, you'd do better to not start a sentence, because you probably can't finish it in eleven seconds. Is that an advantage over "just write what you like, when you like"? ChrisA

On Thu, Jan 30, 2014 at 4:40 PM, Chris Angelico <rosuav@gmail.com> wrote:
It *not cut-off*. It is *sync*. So, what do you do when two-week sync rolls around.. You list the status, say what was the problem with completing as you're planned, say if you need help, if there is something that could have helped to avoid hurdles you had that led to divergence from the plan, and you also communicate your vision about chances of this particular thing to see the light in the next two weeks.
It doesn't matter for you, because you work alone. But it still does worth for other people, so if you run out of time and have a clear understanding that over next three months you won't be able to work on this feature, and you've made it clear during sync, you at least can enable others to look into this problem and hack it for you, or you can *freeze* it properly with all work-in-the-process that is necessary for someone to pick it up later.
There are *jobs*, yes. People choose what to do from existing backlog sorted by some criteria (wishes?) or may develop their own idea. But.. That doesn't mean they should *finish* the job in this time period. Jobs could be split into tasks for synchronization between people, and you are free to make the task that you *will* be able to complete in the time span that you've given. It is your own challenge. *research*, *triage*, *make a writeup* are all tasks that are not directly related to a problem, but if they yield some results for others to sync with, they worth to be mentioned. In my practice this sort of question came from people who undergo formal Scrum training and was told that at the end of each iteration you should deliver a complete feature set that was planned with all documentation and related materials. This keeps people motivated to complete the hard things. But Agile doesn't place this restriction - it is flexible to choose what you want to deliver at the end. The main benefit from the iterative process is that when people start to make goals that are public to everyone else, and then these goals fail, it is possible to make the analysis about the process - how to save time and make the whole collaboration stuff more fun.
The advantage is that if I set a goal to reply to this thread in two weeks, I have better chances to finally find the time to do this in two weeks.

anatoly, if you are trying to change the development process, you're making two big mistakes: 1. You are late by twentysomething years. 2. You are trying to change the development process from the outside. That never works. In the world of free software changes can only be made from the inside. First become a good citizen, a valuable contributor, then propose changes to the process. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Jan 30, 2014, at 5:25, anatoly techtonik <techtonik@gmail.com> wrote:
Do you have any examples of an open source project (and not a company-driven one) that applied agile methodology and gained any benefits? Showing something concrete like that would make a far better argument than just rambling about what might be possible.

On Thu, Jan 30, 2014 at 9:59 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
Yes. A lot of if you read "agile methodology" as "flexible set of practices to organize a team work". SCons before migration from tigris.org [1] implemented a weekly bug triaging [2] and sync / planning sessions on IRC [3]. UFO:AI implemented roadmapping [4,5] and monthly progress reports on the front page [6]. Mercurial uses time-based release practice for "improving planning process" [7]. Subversion roadmap + status visibility [8]. 1. http://scons.tigris.org/issues/reports.cgi?state=Open+issues&x=Assigned+to&y=Milestone 2. http://scons.org/wiki/BugParty 3. http://scons.org/wiki/BugParty/IrcLog2011-04-10 4. http://ufoai.org/wiki/TODO/Roadmap 5. http://ufoai.org/wiki/TODO 6. http://ufoai.org/wiki/News 7. http://mercurial.selenic.com/wiki/TimeBasedReleasePlan 8. https://subversion.apache.org/roadmap.html Trac can be seen as managed by Edgewall, but many projects that use Trac implicitly implement roadmapping and iterations too http://trac.edgewall.org/roadmap These only those project that I had my own hands on experience with and sent code to, so I am certain that there are even more of these practices in other open source projects that combined make these even be better. Addressing your fear about that agile processes can not be sustained outside of company environment. I think that agile is meant to solve boredom and stress problems, to be flexible and to help people learn tools and methodologies to have fun from joint work. As a children we all enjoy playing games with interesting rules and challenges. This doesn't change with age. What changes is that other people and companies want to control the people and adopt otherwise good things in their awkward and unsuitable business environments. Imagine children play in business suits, and for me it is ridiculous and it doesn't change with age of those children. I think that open source communities are free from all this corporate bullsh*t and can do better at supporting fun, chaotic and decentralized team work. They just never tried to focus on this process.

anatoly techtonik writes:
Yes. A lot of if you read "agile methodology" as "flexible set of practices to organize a team work".
You're missing the point. Agile methodology is about *reducing* flexibility in interaction and *increasing* organization, by imposing practices that increase productive contacts among developers without (hopefully) imposing much "bureaucracy." That works extremely well if the community needs more structured workflows, not least because the lack of hierarchical bureacracy appeals to programmers used to working in chaotic environments. However, Python long ago developed structured cooperation that seems to me to be working very well for the existing developer community. What you are suggesting is not just introducing an "option" to use agile methodologies, but a proposal to *change* the workflow. This will almost certainly be inconvenient and reduce participation by existing contributors. In other words, increasing bureaucracy. I really don't see any benefit to Python in adopting your proposals. The "bureaucracy" involved in Python processes is both minimal and useful -- it directly contributes to the extremely high quality of successive Python releases.

On 8 Feb 2014 07:44, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
It's also deliberately structured to create *less* work for the core developers (and PEP 462 is a proposal to introduce even more automation to eliminate some of the current more tedious parts). The thing about the various Agile models are that they are a tool to improve communications flow between a development team and the rest of the company they work for. It's pretty good at that task, but it requires a highly cohesive team, working on short time frames to meet the needs of a particular business. This is the complete opposite of the way a relatively loose collaborative project like CPython works - each of the core developers is contributing for our own reasons, and while we do self-impose deadlines in order to actually get things shipped, that's largely voluntary - if a feature isn't ready, it isn't ready, and slips to the next release. The contributor documentation we provide is there not only for our own reference, but also to help people get involved if they want to, both because there's a natural attrition rate to open source development (so current developers move on and need to be replaced by new contributors), and also because the standard library is large and we can always use more help (and PEP 462 is largely about making more effective use of the help we *already* receive). The conflict between the core development team & Anatoly has always been that he wants *us* to change *our* practices to accommodate *him*. He first wanted us to move all development discussions to Google Wave because *he* preferred it to email. Then he wanted the PSF to drop the CLA relicensing terms, even though we need them to account for the CNRI licensing history, and even after a PSF director sat down with him at the PyCon US sprints to explain the terms and the need for them. Most people that refuse to sign the CLA are polite and either walk away entirely, or recognise that refusing to sign it will greatly restrict their ability to contribute constructively. Anatoly, by contrast, continues to try to interact with the core development team as if he was our direct manager, and then acts surprised when people react badly to his completely unjustified sense of being entitled to tell us what to do (as well as his making proud declarations of the fact that he has deliberately chosen not to read the existing contributor documentation, because he finds doing such a thing boring). Cheers, Nick.

On Wed, Jan 29, 2014 at 4:57 PM, Chris Angelico <rosuav@gmail.com> wrote:
There is a big difference between people who invent things and do things. I am a lazy bastard who can not do anything and sustain its job, because he is constantly inventing new stuff that no one is able to implement. Over the years I realized that the only good that I can do to humanity is to develop a sustainable model. So far it didn't happen, because it appeared that people only work on their own ideas. I don't own my ideas - they are free for everyone to explore and discuss. So if there is anything valuable - take it. I don't need power over project or money or anything in between. Next day there will be another idea and another discussion. It is nice to see communities that can develop ideas, that can realize that people are different and use the potential of that people are capable for to a full degree. It is also nice to see the evolution of people to act in a new roles that are uncommon for them. You won't like it, but it is also nice to see how people become worse, because they are human species and to realize that everyone is imperfect. What is not so nice is to see good things fail, because people can not reuse technology to help them to deal with human factor.
Ok. In short. There is only one advantage: - increased visibility which in turn results in - increased interest which in turn results in - increased participation. What problem does agile solve. There is one big problem that "increased participation" is actually the negative factor for existing contributors, because it takes more time from them. Where does this "more time" comes from? In current model: - increased participation == increased communication If you constantly communicate, you don't have time for development (probably the things that you like the most). How does agile help with that? "agile" means just that - "flexible". If you see the problem, you are not saying "we are all developers, nobody is interested in communications". No, instead you're saying -- ok, we have a communication problem, what can we try? In current model, you can not try anything, because you can not set goals. Goals is something that is at least: - Measurable - Time-bound There is no time bounds, there is no measurement. These are not part of the process, so you don't have even any means to solve the communication and time deficiency problem. If we have two weeks cycle, we can at least set goals.

On Wed, Jan 29, 2014 at 11:29 PM, anatoly techtonik <techtonik@gmail.com> wrote:
There's a fundamental misunderstanding behind this, I think. Contributions are valued, yes, but the purpose of an open source project does not begin and end at "encouraging contributions from every person on the planet". The goal of Python is to be a useful and usable programming language, and if that's best served by a single person doing all the coding, then that's how the project should be run. (I'm preeeeeetty confident that's not the case, though.) There's a general feeling around the world that dictatorships are bad, democracy is good, and the more people you have involved in something, the better. While this is not entirely false, it's not entirely true either. In the Bible, in the book of Proverbs, God tells us several times that multiple people's advice is of value. [1] [2] [3] But that's advice, not decision making. When it comes down to a final decision, it's almost always best to have a single person decide. A business has a CEO, an orchestra have a conductor, there's only one steering wheel in a car. And ultimately, trying to make every single thought behind every single decision public is counter-productive too. Ever tried to answer a child's "Why? Why? Why?" machine-gun? Yeah. On another project, I've contributed a large number of patches. Some fix bugs, some add features, some just fix little typos in documentation. All of them were simply submitted to the core team, reviewed, and ultimately applied, rejected, or modified. I'm not a core dev. I can't push to the git repository. But if I were to be given that power, it would be for reasons of convenience (if the core devs decide that all my patches are getting applied anyway, and it's easier for them to let me push my own), not transparency. You want to know what's going on? Get involved. Then you'll know. The people who care about the project will find a way to contribute. That's a fundamental of the open source model. You don't like the agreement that has to be signed before your patches will be accepted? Then contribute by reviewing other people's patches, or verifying bug reports, or whatever. Onus is not on the python.org legal team to make everything work for you; it's their job to make everything work for the PSF. I haven't looked into the specifics of the agreement in detail, but I'm confident that the PSF would not demand something just for the sake of bureaucracy, so I'd trust that there's good reason for all of it. (And hey. if you don't want to sign that, you can just declare that your contributions are public domain, IIRC.) I'm sure it's very American to demand that the people in power tell you what they're doing. (Or insert any other country name there, though I think the USA is at the forefront of this.) Trouble is, open source projects simply aren't built that way. ChrisA [1] Prov 11:14 http://www.biblegateway.com/passage/?search=proverbs%2011:14 [2] Prov 15:22 http://www.biblegateway.com/passage/?search=proverbs%2015:22 [3] Prov 24:6 http://www.biblegateway.com/passage/?search=proverbs%2024:6

You want to know what's going on? Get involved. Then you'll know
+1. It's odd to complain about the project's organization and processes when you haven't actually had any real experience with either. Getting involved in some project run by other people isn't easy, but it's not really that hard either in the world of open source. On Wed, Jan 29, 2014 at 11:36 PM, Amber Yust <amber.yust@gmail.com> wrote:

On Thu, Jan 30, 2014 at 2:52 AM, Haoyi Li <haoyi.sg@gmail.com> wrote:
I first met that concept with community groups, rather than open source projects, but the result is similar. There were people who desperately wanted to be in that "inner circle" of people who knew, a year in advance, which Gilbert & Sullivan operas were going to be performed, and who'd be directing them, and who would be playing which roles, and so on. It's all announced sooner or later, but for some people, they'd really rather it be "sooner" than "later". Well, that's easily solved. Serve on the society's committee - then you know what's happening, because you're helping to make it happen. And if you're happy with a lesser advantage from lesser work, just swing by and help us with our mail-out. You get to read the info we're sending before we send it out... because you're helping us to send it out. In one stroke, you call the bluff of anyone who just wanted handouts of information, satisfy the desires of those who really care, and maybe even get some extra help running the (all-volunteer) organization. I call that a win! :) ChrisA

On Wed, Jan 29, 2014 at 6:52 PM, Haoyi Li <haoyi.sg@gmail.com> wrote:
I know that my experience is nothing compared to other people, and therefore I am even more interested to get feedback from people, deeply involved in the organization and processes, about good and bad things in the original idea of "Iterative Development" presented in the first thread message under this subject.

On Jan 28, 2014, at 23:44, anatoly techtonik <techtonik@gmail.com> wrote:
Yet another idea that some of you will find strange.
You do realize that Python is an open source project? And that the only people who work on it full time are the ones being paid by some organization that generally has its own priorities?

On Wed, Jan 29, 2014 at 11:57 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
Yes, captain. However, I fail to see why to ask the question. If you're saying that open source projects can't have any kind of methodology to save time and coordinate efforts more efficiently, then I have to disagree with you. Example from good old times of 2011 http://scons.org/wiki/BugParty I am certain there other open source projects with similar processes.
And that the only people who work on it full time are the ones being paid by some organization that generally has its own priorities?
You don't need to work full time to participate in two week cycle. As I answered to Ethan, it is not development cycle time. It is just ordinary two weeks time. You choose what you can do in these two week and do this. You may find that you have more time than you've planned during this time, so you can see who is working on what and help them (if possible).

On Wed, Jan 29, 2014 at 7:27 PM, Chris Angelico <rosuav@gmail.com> wrote:
More fun with collaboration. For some people it is not fun to grok the bugs they don't personally need to be solved. Sometimes because of complexity of the problem, but helping some else may be fun. Current bug tracker doesn't show: 1. what is important for people who think like you are 2. what is the current development focus So you can not plan how to spend your time more effectively and how to help with development.
Please explain to us the benefits of the Agile model, as they apply to a loose collaboration.
As I said, there is no single Agile model. Model can be agile (adapting, willing to change, flexible), natural or rigid. In rigid model you don't have choice. Take the bug, commit, release. In natural model you may have additional and optional steps. In agile model, you have a feedback loop that allows to estimate how good the model actually is and experiment with it to see if it can be better.

On 30/01/2014 12:52, anatoly techtonik wrote:
So you can not plan how to spend your time more effectively and how to help with development.
Core dev time could be used more effectively if they weren't sidetracked by non-issues e.g. blithering idiots who keep reopening issues on the bug tracker. I won't mention any names. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 31 Jan 2014 04:17, "Mark Lawrence" <breamoreboy@yahoo.co.uk> wrote:
by non-issues e.g. blithering idiots who keep reopening issues on the bug tracker. I won't mention any names. Mark, as annoying as Anatoly is, this is still a violation of the list code of conduct. If you find him too irritating to allow you to maintain civility on the core lists when dealing with him, set your mail client to ignore his messages (that's what most of the core devs have been doing for quite some time). Anatoly already got himself banned from bugs.python.org with his antics, and his moderation flag is set on all the core mailing lists. At the rate he is going, he is not encouraging anyone to reconsider either decision, and it's still possible for that moderation flag to be upgraded to an outright ban from the mailing lists if the mods decide it would be appropriate. Regards, Nick.
-- My fellow Pythonistas, ask not what our language can do for you, ask what
you can do for our language.

On 31/01/2014 11:41, Nick Coghlan wrote:
Who says I was getting at Anotoly? Unless the English language has changed without my knowledge, you'll find that "idiots" and "names" are plural and not singular. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 2:13 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
That's a perfectly valid argument, in the same way that this is perfectly valid code: # utils.py import math math.pi = 3.159 SECONDS_PER_MINUTE = 60 def minsec(sec): global SECONDS_PER_MINUTE SECONDS_PER_MINUTE+=2 return sec//SECONDS_PER_MINUTE, sec%SECONDS_PER_MINUTE def format_time(sec): min,sec = minsec(sec) return "%02d:%02d"%(sec,min) It's all perfectly legal Python, but it breaks all sorts of conventions, and you know it. In the context of this thread, it was obvious to everyone what you were saying, and hiding behind the technicality of plurality doesn't help you. Do please be honest with yourself and us. ChrisA

On 31/01/2014 15:26, Chris Angelico wrote:
Asperger Syndrome sufferers are always honest. Sadly I find it a major weakness that I have to live with. We also take things literally and write things literally. So your "obvious to everyone what you were saying" to me is clearly incorrect. Please withdraw the comment. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 2:45 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I know what it's like to live with Aspergers, I have it myself (at least, not formally diagnosed but it seems pretty likely). And I do put my foot in my mouth pretty often. But that doesn't mean that I can hide behind it as a shield when it's this obvious. You knew full well what you were saying when you said you wouldn't mention any names. Now, I do enjoy a good upper-class British insult-fest. That's a major part of what makes quite a few British comedies work - the utterly courteous, yet bitingly cutting, wit, barb, and counter-barb. The tenor explains to the soprano that he was just disguised as a member of the band, that he's really a much more important person, and she says that she knew he was in disguise the minute she heard him play. But when that wit is wielded inappropriately, the proper response is a graceful apology or retraction... or, if circumstances demand, a barbed retraction ("I implied in the House last week that the Hon Member had the intelligence of a stuffed egg. This was inappropriate, and I formally apologize for and retract this analogy. My breakfast egg today deserved no less."), but you have to be VERY sure of your ground before you take that option - claiming Aspergers is not sufficient. This'll probably sidetrack everyone terribly (for which I'm not sure if I apologize; it might be a good thing for some people to get stuck in TVTropes for a while) but this write-up about Asperger Syndrome gives an excellent comment: http://tvtropes.org/pmwiki/pmwiki.php/UsefulNotes/AspergerSyndrome """ Most genuine Aspies don't see Aspergers as a 'Get Out Of Jerk Ass Free' card, just an explanation. If somebody offends you, then tells you they have Asperger Syndrome and that's why they offended you, you can generally tell if this is true by a simple observation - If the admittance is followed (or preceded) by a genuine apology, it may be true. If it's followed by the expectation that you should now apologise to them for being offended, they're probably just jerks. """ I'll let that speak for itself. ChrisA

On 31/01/2014 16:15, Chris Angelico wrote:
Once again I most certainly *DID NOT*. I knew full well what I was writing. I quite deliberately used plurals for that very purpose. Please in future stick to your bible bashing as you clearly know far more about that than you know about Asperger, with myself having a formal diagnosis. And please don't bother to withdraw your comment now or apologise, I wouldn't accept either as being in any way, shape or form genuine. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 4:32 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I wouldn't withdraw my comment, because I still stand by it. If you genuinely meant no specifics, then when someone pointed out how they interpreted your statement, you would have apologized and made a correction: "I didn't mean anyone in particular, I meant the way there've been 50 issues reopened unnecessarily by 30 different people lately", or something. But that wouldn't be true, would it? You really did mean Anatoly, and that's why you said what you did. Believe you me, I know more than you think I do. Think of Emma from "Once Upon A Time" if you like - a strong ability to detect lying, based on a metric ton of experience with it. ChrisA

On Sat, Feb 01, 2014 at 04:42:04AM +1100, Chris Angelico wrote:
Hi all, this is getting rather meta, in a profoundly unproductive way. Can we stick to software development, Python, and non-personal-or-plural insults, please? thanks, --titus [ <-- wearing moderator hat ] -- C. Titus Brown, ctb@msu.edu

On 31/01/2014 16:28, Ethan Furman wrote:
Your opinion, clearly not mine. Further I don't discuss anything that starts on a Python mailing list with people offline as I don't believe in discussing things behind other people's backs. As for wasting developer time how much has been wasted by various people who've routinely insulted Python and by continuance its developers, and yet they're still allowed to spew their nonsense and get away with it? Yet again we're into the dual standards that annoy me so much, yet for speaking my mind I'm the one in the wrong. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 4:28 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
No, you're not in the wrong for speaking your mind. You're declared to be (or treated as) in the wrong based on an objective analysis of the content and style of your posts. Anatoly is at fault too, but your issues are almost completely tangential to his. They just happen to be in the same thread. Now please, stop talking. Trust me, you're only digging yourself further into a hole. This discussion is way way off topic, and I'm becoming painfully aware that I've said way too much already myself. ChrisA

Am 31.01.2014 18:28, schrieb Mark Lawrence:
Yet again we're into the dual standards that annoy me so much, yet for speaking my mind I'm the one in the wrong.
Would you like to show me a recent post from Anatoly with the word "idiot" in it? Oh right, there isn't one, because he's moderated. Double standards? Georg

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
Asperger Syndrome sufferers are always honest. Sadly I find it a major weakness that I have to live with.
That's unfortunate. Please don't impose it on others too. -- \ “When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney

On 29/01/2014 07:44, anatoly techtonik wrote:
Yet another idea that some of you will find strange.
Instead of coming up with ideas, why not sign the contributors' agreement and come up with code that people can actually use? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Wed, Jan 29, 2014 at 12:29 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
replied to python-legal-sig https://mail.python.org/pipermail/python-legal-sig/2014-January/000070.html

On Wed, Jan 29, 2014 at 3:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Basically, you refuse to sign a contributor agreement, but insist on blaming the PSF for that. Your position is simply unreasonable: You demand that the PSF should either stop demanding a contributor agreement, accept your own personal version of it, or spend a lot of time and energy attempting to explain it to you. You blame the PSF of being a needlessly bureaucratic political body which is giving you a hard time just because it can or because it doesn't care; whatever you may think, that is the opposite of the truth. Furthermore, since you continue to choose to phrase your arguments aggressively and offensively, how can you expect anyone to consider your proposals?? Regarding the contributor agreement, please spend your time and energy understanding it, instead of arguing about it here and blaming other people. Otherwise, stop pestering people about it. What you demand regarding the contributor agreement is not going to happen, period. If you actually care about Python, find a way to contribute helpfully! Even if you believe that we are the ones being stubborn and unhelpful, it is up to you to find a way to work with us productively. For example, I am sure you have noticed that few of your ideas posted here have been helpful in any way, if any at all. I do believe that you think these are good ideas, but surely you must see that nothing good results from your posting them to this list. As it is, you have been harming the development of Python considerably for many months by pestering people on various mailing lists. If you want to help, you must change your behavior! - Tal

On 1/29/2014 2:44 AM, anatoly techtonik wrote:
This is more or less what we do now on an issue by issue basis. At a higher level, releases for the 'next' version already come out at 2 or 3 week intervals from a0 to final. At a higher level, we already have plans for 3.5 that we will start on as soon as 3.4.0 is out or after PyCon. -- Terry Jan Reedy

On Wed, Jan 29, 2014 at 12:47 PM, Terry Reedy <tjreedy@udel.edu> wrote:
It is quite obvious from outside that Python has some kind of process, but it is quite hard to sync to it for people from outside, because it is not open - is not completely clear how the planning is made, which tasks are available for current sprint, what you can help with and how to track the progress.

I haven't been following this thread very closely, but I have to disagree with you here, Anatoly. On Thu, Jan 30, 2014 at 5:24 AM, anatoly techtonik <techtonik@gmail.com> wrote:
It is quite obvious from outside that Python has some kind of process,
Which is well documented in several places. It can be tricky to always find all of those places, but anyone who is interested can ask, and will be quickly shown where to look.
but it is quite hard to sync to it for people from outside,
I'm not sure what you mean here. Every contributor starts from "outside" of Python. I found no difficulty in getting started when I did, and I've seen several people start contributing successfully since then. It would be very hard to go from nothing to suddenly contributing huge patches to the innermost details of Python at a rapid pace, but that's not really what people (especially people new to open source development, like I was) should be doing anyway. Start slow and small, build from there, and it's an easy and painless process.
because it is not open
Here I must disagree emphatically. My entire Python experience shows me that everything about Python is as open as possible. If you want to know something, look for it. If you can't find it, ask for it. If you can't be shown where it is, somebody (even yourself) will write it down somewhere so the next person looking can find it.
- is not completely clear how the planning is made,
I'm not sure what you mean here, what planning? Anything that could be construed as "planning" is done via the PEP process, which is well documented in PEP 1.
which tasks are available for current sprint, what you can help with and how to track the progress.
This is the very definition of a bug tracker, and Python's is quite good for all of this. There could stand to be some upkeep done on some of the older issues: it would be good for an impartial person to pick through and see whether an issue is still a problem, update any patches to apply to current branches, manage the 'easy' tag, add the proper people to the nosy list, etc. This kind of thing would be a great place for someone to contribute. Honestly, just bringing all tracker issues up to date would be a worthwhile sprint task in my opinion. -- Zach

Am 30.01.2014 17:17, schrieb Zachary Ware:
Nowadays the development process is really well documented in the devguide. If anything is still not in there, that should be fixed.
That's the key: *ask* for it. Do not rant that you didn't find something, complain that it wasn't in some random place you expected it, and then not accept help and hints from people that weren't put off replying you in the first place.
We have tried quite a few times to make it clear to Anatoly that there is no "planning" made apart from what you can read about in PEPs and mailing lists. Apparently he thinks there's a secret agenda, when in reality there often is no (shared) agenda at all -- that's in the nature of an open source project. Of course individual developers may have private agendas.
Few people have tried that because it's such a thankless task, but there was definitely progress. cheers, Georg

On Thu, Jan 30, 2014 at 11:15 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Let's pinpoint the conflicting point first - "nature of an open source" - s/a/the/ As I already pointed out, many open source project have planning, and before expanding the idea, let's say that I never had any conspiracy theory behind planning of Python development - I perfectly realize how the chaotic the process is, but that's not clear from outside, and what I am trying to say that not having any visible planning strategy (chaos is a strategy) is bad for any organized effort and more importantly - for an effort to organize. There is a big potential for self-organizing teams in Python community, but that's just didn't happen, because these team can't hold together. They can be organized around bugs (as in bug tracker), issues (as a "problem"), components (stdlib modules), releases (as it works now), tools (independent of core development at all), ideas (as we see in this thread). But to hold on, people from different time zones, cultures, need to sync. Iteration has one awesome and distinctive property - any iteration stripped of all the feature- creeped stuff is just a sync point in time. So, sync point is "subject, place and time". I tried to start with place for pydotorg (see thread few years ago), subject (attempt to split things by module in tracker) - https://bitbucket.org/techtonik/python-stdlib - good indicator of poor development of my skills and now I came to conclusion that the only thing that matters is time. Sync points are important, because they allow a project to be inclusive for people who are not interested in Python development at all, but may want to join later, because they want to make a change. You don't force people to read papers, but let them see hot it works. It is also more entertaining for the brain to watch the real thing and hack on ideas how to make the whole entrypoint more exciting. I can't name any reason why anyone should be excited with Python core developer when faced with a dusty tome of paperwork of ancient contributing wisdom written in largely uncommon English language.
Make it thankful. Make 'implementing a Twisted Highscore for b.p.o' a goal of the next iteration and let people contributions flow. If truck can not pass through gate, somebody get out and lift it. If chaotic effort is ineffective, then coordinated effort can help. There could be coordinator for the one or two iterations, but it can be possible for technology to help with it in the long run if it is worthy. -- anatoly t.

On Thu, Jan 30, 2014 at 7:17 PM, Zachary Ware <zachary.ware+pyideas@gmail.com> wrote:
I haven't been following this thread very closely, but I have to disagree with you here, Anatoly.
That's ok. Kenneth Rietz converted me to fallibilism, and I hope to spread the virus further.
MIT Technology Review had an article about decreasing participation of Wikipedia. Here is the quote: "The main source of those problems is not mysterious. The loose collective running the site today, estimated to be 90 percent male, operates a crushing bureaucracy with an often abrasive atmosphere that deters newcomers who might increase participation in Wikipedia and broaden its coverage. In response, the Wikimedia Foundation, the 187-person nonprofit that pays for the legal and technical infrastructure supporting Wikipedia, is staging a kind of rescue mission. The foundation can’t order the volunteer community to change the way it operates. But by tweaking Wikipedia’s website and software, it hopes to steer the encyclopedia onto a more sustainable path." http://www.technologyreview.com/featuredstory/520446/the-decline-of-wikipedi... Bureaucracy deters newcomers, and knowing that most people don't read, but scan, I believe that Python should also think about ways to tweak software and process for new generations instead of placing bureaucratic filters to allow only those who comfortable with old ways of doing things to pass by. Most people are lurkers and won't even dare to ask a question especially as (silly) as the one about the process seems.
And if you just don't have a time for that? If you have a cancer and going to die in the next couple of years if technology won't be advance enough to save you? People have different goals in mind and you're trying to impose your own way on them, which won't suit them. That's why, again, I am not proposing to replace current development practice. I just want to see that people can see benefits in following a parallel route and try to think about those benefits, and not about intrusiveness about some idea in comfort zone of their established workflow. Which leads me the the interesting observation that if people used to things, they are less likely to discuss specific arguments, because there is no problem for them personally. Which divides the community into contributor and non-contributors and makes the communication between parties hard (if not impossible at all).
I agree that Python strives to be as open as possible, but there are projects that do it better. The notion of open is subjective, but the criteria that I use is if information is buried under piles of other information and is tricky to find - it is not truly open. In strictly technical terms of information theory - if information didn't reach the recipient - the information is unreachable. But.. it is my general point of view that Huxley wins over Orwell. In original mail there was the specific notion of open that you generalized. I stated reasons why the process is not open, one of which you've left below:
I believe that question constitutes the answer. There is not planning, so it is not clear what's going on, so it is not possible to jump in and help. Yes, you can ask, but really - who'd do this? Internet has many other things to do than messing with all this mailing list communication stuff that people find "easy".
Ok. I opened the tracker. Who's doing what currently, what is being done for the next release and what can I help with? I don't see the answer there. I am pretty sure it is a documented somewhere on the internet, but I already look into internet I don't see it.
The only problem that if you're not a committer, you don't have any of the privileges to do the stuff what you've mentioned above. But that's not the reason why the whole useful stuff is not done right now. The reason is that current process doesn't support it or make the whole process not fun. I am glad that we have a first *recurring* task that can be solved with the idea of iterative development process. It is "bug triaging" task which can be decomposed into more fun "cave hunting" task that addresses the most ancient issues to refactor, reclassify and deobfuscate them, e.g. push the progress in incremental way. For this to work, the progress should be measurable for two weeks period: [ ] entomology works for open species in range 1034-2000 (xx total) Which when completed is accompanied with analysis on the problems encountered and recommendation (consensus) what do to with each. specimen no.1034 - thread started from a patch, which was discussed and agreed in ML, LGTM required author to do nitpicks with user comments and more tests, which never happened. specimen filled in 2007-08-27 for Python ???, after 1 year 5 months reworked by core contributor for Python ???, missed the 2.7 deadline, planned for 3.2 and seems like missing it too. I don't know about you, but I see here a few very interesting problems in the process of dissecting this specimen that will be visible after the first iteration and what could and will be addressed in the next iterations by people who choose to work not on Python, but on bug tracker instead. That is the flexibility I am talking about.

On 01/28/2014 11:44 PM, anatoly techtonik wrote:
It is a parallel Python development process. It doesn't affect or replace current practice, so nobody gets hurt.
So you're saying that we would have the current model, plus this agile model?
What "hidden" communication? Talking in person or on IRC? Instead of ... where?
inclusiveness (eliminate exclusive rights and privileges)
Exclusive rights? You mean let any piece of code get committed?
and accessibility (eliminate awkward practices and poor user experience).
It is not possible to please everyone; it is also not possible to ensure a "good user experience" for everyone.
The idea is to split development of Python into two weeks cycle.
80 hours? Do you have any idea how long it takes some of us to put in 80 hours of Python development time? -- ~Ethan~

On Wed, Jan 29, 2014 at 11:29 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
I am saying that you're not forced to follow agile model if you don't like it. You can do what you do as you did before.
If information doesn't reach the recipient who want to read it, it is "hidden". Even if you talk in public channel on IRC, the information is hidden from me if I was not connected and channel doesn't have public logs.
inclusiveness (eliminate exclusive rights and privileges) Exclusive rights? You mean let any piece of code get committed?
There are many exclusive rights that keep people off from contributing. I don't want to touch them here, because it will move the thread into different area. To make it more specific "inclusiveness" on the process is the process too. You start with people who have full exclusive rights and contributing then compare them to people who are willing to help, but don't do this. Then you remove the obstacles to include these people.
That's a general claim. I am sure that it is possible to reach the point where everyone agree that their experience is "good enough user experience". And there is a dedicated time in the process (retrospective) to work on just on that.
It is not development time. These two weeks cycle is just ordinary time, which may include 15 minutes of development time, a week or nothing. It is up to you - how much are you willing to spend.

On Wed, Jan 29, 2014 at 11:29 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Then if you care, connect. It's not hidden if you have the power to access it. Here's a suggestion: Fork Python (that's legal, that's what open source means) and start development using the model you advocate. If it's massively better than what's happening, (a) developers will flock to your model, and (b) the project could be completely handed over to you, as happened with GCC. Or alternatively, explain to us here what the real advantages are of your new model. So far, what I've seen is "hey, here's an idea", and not "here's what this idea will do to benefit Python"; and the idea itself looks more suited to a big business than to open source. Maybe someone who's actually used Agile will know what's so wonderful about it, but unless every core dev *has*, a bit of explanation will help. ChrisA

On 29 January 2014 23:57, Chris Angelico <rosuav@gmail.com> wrote:
Plenty of us have used it, and we know it's an entirely inappropriate model for open source development projects with broad asynchronous participation, as the time commitment needed to make the short cycle work is antithetical to loose collaboration. It works well for a focused team supporting a single application to meet the specific needs of a single business, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, Jan 29, 2014 at 5:18 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
About *Agile* I tried to avoid the word Agile, but since you saying that you've used that, let us agree on terminology. In my world *agile* means *flexible*, which means *able to change*. It doesn't mean *scrum* or *two weeks sprint* or any of the hardcoded value that you put behind the phrase of "entirely inappropriate model for open source". Not that that's clear, let's move on. "Asynchronous participation" is called "distributed development", and it is used both by open source and by commercial companies a lot. If Yahoo terminated this practice and Google didn't even try - that's a problem of management of these companies. It doesn't mean it doesn't work for professional teams or people *interested* in interacting this way. Agile helps to analyze and improve distributed development processes the same way it does for rigid corporate practices. You say - "short cycles" are bad. In agile I'd say - let's try and see why. Maybe it's cycles what are bad, maybe it's people who can not sync this often, maybe there is a technical problem with communication that can be resolved by using right tools.

On Thu, Jan 30, 2014 at 10:56 PM, anatoly techtonik <techtonik@gmail.com> wrote:
The very concept of a cycle suggests a system that's more suited to a business environment than general open source development. Forcing people to pick up and set down work might be useful in the very short period just before a version release (I've been seeing some stuff about Argument Clinic - btw, kudos to the tireless people doing that, it's a huge job - and how some of the work will be deferred to 3.5), but most of the time, it's completely unnecessary. In big business, you might have a couple dozen programmers working on some particular job; in that two week cycle, each one could potentially put in quite a few hours. I heard a figure of 80 hours quoted, but I'm dubious about how many actual dev hours a salaried programmer would get done, in between meetings and whatnot. Still, could easily be upwards of 50 hours. Forcing everyone to stop and re-check things every fifty dev hours doesn't sound too bad. Now look at volunteers. Two weeks might be anywhere from zero hours up to... well, the upper end doesn't matter. But it could easily be just a single dev hour in that time. Are you then going to force this person to set aside what he's partially done, because of some arbitrary break point? Now, what happens if you take Agile and eliminate the two-week period? It begins to look very much like a pool of issues on a bug tracker. You have a pile of stuff to do, someone picks up something he feels like doing, posts a result back. Hmm, I wonder if that might be what's already happening... Do you see now why I was, without any experience of Agile, already dubious about its merits? And that even before Nick stated from experience that it's not going to help. Ideas are all very well, but they're useless without some form of test-bed. The only perfect way to find out if an idea works or not is to try it, and the onus is on the inventor to risk something for his idea. Put the theory to work on some project. Once you can point to some clear advantages *in practice*, you'll be able to recommend this to other people. So... fork CPython, tell us all how wonderful your version is going to be, and then show us how, in two weeks, or four weeks, or six weeks, you can do amazing stuff with a motley crew of programmers. Then we'll all take notice. ChrisA

On Thu, Jan 30, 2014 at 3:49 PM, Chris Angelico <rosuav@gmail.com> wrote:
The cycle is needed when you need some kind of visibility in the process. For business environment it is critical, because it has to control the spendings. For open source environment it is critical for people, because they need to plan their time.
Again, it is not forcing anyone. It is just a process. You are free to fail you development goal. It is not a business - there is nobody to fire you or say that you're underperforming. There is no heroism either. If you do not know your development pace, you can try and measure it, if you do know, you just realistically state what are you working on and if you need help with that.
Single dev hour is ok if you reached your goal. That's the point. You set the goals - you reach them. If you didn't reach them - you analyze and see what could be done better. It is all in relaxing and free manner, unlike the bloody corporation culture. You may invite other people to join the fun. People can find what are you working on and propose help. This is the process.
That's a crowdsourced development, not a team work in distributed environment. And there is no place for team to appear if everybody looks at a big pile of garbage and chooses the shiny metal plate that is precious only yo him. The environment you've described is not encouraging team birth and collaboration in any way. More than that - it looks like people would even oppose if commercial development teams would propose their work. In the past it happened already with "unladen swallow" project. Current development process couldn't munch the result if this work, and people didn't even try to adjust the process to make the future efforts possible.
I don't want core devs to accept this process at all. I don't want to sell it to them and I don't want them to follow it. =) It is completely optional, and I just don't want them to make more obstacles to new people who would like to try these. It may happen that resistance to change for open source projects may be bigger than in organizations. I just want to make sure that people aware that applying agile methodology to open source development is possible and I am inclined that it brings more positive improvements for the Python itself than de-facto development processes.

On Fri, Jan 31, 2014 at 12:25 AM, anatoly techtonik <techtonik@gmail.com> wrote:
Let's say you pick up something that's going to turn out to take you three dev hours. You then put one hour of work into it, and the two-week cut-off rolls around. What do you do? In the current model, there is no cut-off, so you just keep your work where it is until you find the time to finish it. Then you format it as a patch, put it on the tracker issue, and move on. (Or, if you're a core dev, I suppose you push it, see if the buildbots start looking red and angry, and then move on. Either way.) It doesn't matter if that took you one day, two weeks, or three months. What you're suggesting is that people should conform to an arbitrary number-of-days cutoff. That means that if the cut-off is getting close, there's a *dis*incentive to pick up any job, because you won't be able to finish it. Imagine if, when writing up a post for the mailing list, you had to finish each sentence inside one minute as per the clock. If it's currently showing hh:mm:49, you'd do better to not start a sentence, because you probably can't finish it in eleven seconds. Is that an advantage over "just write what you like, when you like"? ChrisA

On Thu, Jan 30, 2014 at 4:40 PM, Chris Angelico <rosuav@gmail.com> wrote:
It *not cut-off*. It is *sync*. So, what do you do when two-week sync rolls around.. You list the status, say what was the problem with completing as you're planned, say if you need help, if there is something that could have helped to avoid hurdles you had that led to divergence from the plan, and you also communicate your vision about chances of this particular thing to see the light in the next two weeks.
It doesn't matter for you, because you work alone. But it still does worth for other people, so if you run out of time and have a clear understanding that over next three months you won't be able to work on this feature, and you've made it clear during sync, you at least can enable others to look into this problem and hack it for you, or you can *freeze* it properly with all work-in-the-process that is necessary for someone to pick it up later.
There are *jobs*, yes. People choose what to do from existing backlog sorted by some criteria (wishes?) or may develop their own idea. But.. That doesn't mean they should *finish* the job in this time period. Jobs could be split into tasks for synchronization between people, and you are free to make the task that you *will* be able to complete in the time span that you've given. It is your own challenge. *research*, *triage*, *make a writeup* are all tasks that are not directly related to a problem, but if they yield some results for others to sync with, they worth to be mentioned. In my practice this sort of question came from people who undergo formal Scrum training and was told that at the end of each iteration you should deliver a complete feature set that was planned with all documentation and related materials. This keeps people motivated to complete the hard things. But Agile doesn't place this restriction - it is flexible to choose what you want to deliver at the end. The main benefit from the iterative process is that when people start to make goals that are public to everyone else, and then these goals fail, it is possible to make the analysis about the process - how to save time and make the whole collaboration stuff more fun.
The advantage is that if I set a goal to reply to this thread in two weeks, I have better chances to finally find the time to do this in two weeks.

anatoly, if you are trying to change the development process, you're making two big mistakes: 1. You are late by twentysomething years. 2. You are trying to change the development process from the outside. That never works. In the world of free software changes can only be made from the inside. First become a good citizen, a valuable contributor, then propose changes to the process. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.

On Jan 30, 2014, at 5:25, anatoly techtonik <techtonik@gmail.com> wrote:
Do you have any examples of an open source project (and not a company-driven one) that applied agile methodology and gained any benefits? Showing something concrete like that would make a far better argument than just rambling about what might be possible.

On Thu, Jan 30, 2014 at 9:59 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
Yes. A lot of if you read "agile methodology" as "flexible set of practices to organize a team work". SCons before migration from tigris.org [1] implemented a weekly bug triaging [2] and sync / planning sessions on IRC [3]. UFO:AI implemented roadmapping [4,5] and monthly progress reports on the front page [6]. Mercurial uses time-based release practice for "improving planning process" [7]. Subversion roadmap + status visibility [8]. 1. http://scons.tigris.org/issues/reports.cgi?state=Open+issues&x=Assigned+to&y=Milestone 2. http://scons.org/wiki/BugParty 3. http://scons.org/wiki/BugParty/IrcLog2011-04-10 4. http://ufoai.org/wiki/TODO/Roadmap 5. http://ufoai.org/wiki/TODO 6. http://ufoai.org/wiki/News 7. http://mercurial.selenic.com/wiki/TimeBasedReleasePlan 8. https://subversion.apache.org/roadmap.html Trac can be seen as managed by Edgewall, but many projects that use Trac implicitly implement roadmapping and iterations too http://trac.edgewall.org/roadmap These only those project that I had my own hands on experience with and sent code to, so I am certain that there are even more of these practices in other open source projects that combined make these even be better. Addressing your fear about that agile processes can not be sustained outside of company environment. I think that agile is meant to solve boredom and stress problems, to be flexible and to help people learn tools and methodologies to have fun from joint work. As a children we all enjoy playing games with interesting rules and challenges. This doesn't change with age. What changes is that other people and companies want to control the people and adopt otherwise good things in their awkward and unsuitable business environments. Imagine children play in business suits, and for me it is ridiculous and it doesn't change with age of those children. I think that open source communities are free from all this corporate bullsh*t and can do better at supporting fun, chaotic and decentralized team work. They just never tried to focus on this process.

anatoly techtonik writes:
Yes. A lot of if you read "agile methodology" as "flexible set of practices to organize a team work".
You're missing the point. Agile methodology is about *reducing* flexibility in interaction and *increasing* organization, by imposing practices that increase productive contacts among developers without (hopefully) imposing much "bureaucracy." That works extremely well if the community needs more structured workflows, not least because the lack of hierarchical bureacracy appeals to programmers used to working in chaotic environments. However, Python long ago developed structured cooperation that seems to me to be working very well for the existing developer community. What you are suggesting is not just introducing an "option" to use agile methodologies, but a proposal to *change* the workflow. This will almost certainly be inconvenient and reduce participation by existing contributors. In other words, increasing bureaucracy. I really don't see any benefit to Python in adopting your proposals. The "bureaucracy" involved in Python processes is both minimal and useful -- it directly contributes to the extremely high quality of successive Python releases.

On 8 Feb 2014 07:44, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
It's also deliberately structured to create *less* work for the core developers (and PEP 462 is a proposal to introduce even more automation to eliminate some of the current more tedious parts). The thing about the various Agile models are that they are a tool to improve communications flow between a development team and the rest of the company they work for. It's pretty good at that task, but it requires a highly cohesive team, working on short time frames to meet the needs of a particular business. This is the complete opposite of the way a relatively loose collaborative project like CPython works - each of the core developers is contributing for our own reasons, and while we do self-impose deadlines in order to actually get things shipped, that's largely voluntary - if a feature isn't ready, it isn't ready, and slips to the next release. The contributor documentation we provide is there not only for our own reference, but also to help people get involved if they want to, both because there's a natural attrition rate to open source development (so current developers move on and need to be replaced by new contributors), and also because the standard library is large and we can always use more help (and PEP 462 is largely about making more effective use of the help we *already* receive). The conflict between the core development team & Anatoly has always been that he wants *us* to change *our* practices to accommodate *him*. He first wanted us to move all development discussions to Google Wave because *he* preferred it to email. Then he wanted the PSF to drop the CLA relicensing terms, even though we need them to account for the CNRI licensing history, and even after a PSF director sat down with him at the PyCon US sprints to explain the terms and the need for them. Most people that refuse to sign the CLA are polite and either walk away entirely, or recognise that refusing to sign it will greatly restrict their ability to contribute constructively. Anatoly, by contrast, continues to try to interact with the core development team as if he was our direct manager, and then acts surprised when people react badly to his completely unjustified sense of being entitled to tell us what to do (as well as his making proud declarations of the fact that he has deliberately chosen not to read the existing contributor documentation, because he finds doing such a thing boring). Cheers, Nick.

On Wed, Jan 29, 2014 at 4:57 PM, Chris Angelico <rosuav@gmail.com> wrote:
There is a big difference between people who invent things and do things. I am a lazy bastard who can not do anything and sustain its job, because he is constantly inventing new stuff that no one is able to implement. Over the years I realized that the only good that I can do to humanity is to develop a sustainable model. So far it didn't happen, because it appeared that people only work on their own ideas. I don't own my ideas - they are free for everyone to explore and discuss. So if there is anything valuable - take it. I don't need power over project or money or anything in between. Next day there will be another idea and another discussion. It is nice to see communities that can develop ideas, that can realize that people are different and use the potential of that people are capable for to a full degree. It is also nice to see the evolution of people to act in a new roles that are uncommon for them. You won't like it, but it is also nice to see how people become worse, because they are human species and to realize that everyone is imperfect. What is not so nice is to see good things fail, because people can not reuse technology to help them to deal with human factor.
Ok. In short. There is only one advantage: - increased visibility which in turn results in - increased interest which in turn results in - increased participation. What problem does agile solve. There is one big problem that "increased participation" is actually the negative factor for existing contributors, because it takes more time from them. Where does this "more time" comes from? In current model: - increased participation == increased communication If you constantly communicate, you don't have time for development (probably the things that you like the most). How does agile help with that? "agile" means just that - "flexible". If you see the problem, you are not saying "we are all developers, nobody is interested in communications". No, instead you're saying -- ok, we have a communication problem, what can we try? In current model, you can not try anything, because you can not set goals. Goals is something that is at least: - Measurable - Time-bound There is no time bounds, there is no measurement. These are not part of the process, so you don't have even any means to solve the communication and time deficiency problem. If we have two weeks cycle, we can at least set goals.

On Wed, Jan 29, 2014 at 11:29 PM, anatoly techtonik <techtonik@gmail.com> wrote:
There's a fundamental misunderstanding behind this, I think. Contributions are valued, yes, but the purpose of an open source project does not begin and end at "encouraging contributions from every person on the planet". The goal of Python is to be a useful and usable programming language, and if that's best served by a single person doing all the coding, then that's how the project should be run. (I'm preeeeeetty confident that's not the case, though.) There's a general feeling around the world that dictatorships are bad, democracy is good, and the more people you have involved in something, the better. While this is not entirely false, it's not entirely true either. In the Bible, in the book of Proverbs, God tells us several times that multiple people's advice is of value. [1] [2] [3] But that's advice, not decision making. When it comes down to a final decision, it's almost always best to have a single person decide. A business has a CEO, an orchestra have a conductor, there's only one steering wheel in a car. And ultimately, trying to make every single thought behind every single decision public is counter-productive too. Ever tried to answer a child's "Why? Why? Why?" machine-gun? Yeah. On another project, I've contributed a large number of patches. Some fix bugs, some add features, some just fix little typos in documentation. All of them were simply submitted to the core team, reviewed, and ultimately applied, rejected, or modified. I'm not a core dev. I can't push to the git repository. But if I were to be given that power, it would be for reasons of convenience (if the core devs decide that all my patches are getting applied anyway, and it's easier for them to let me push my own), not transparency. You want to know what's going on? Get involved. Then you'll know. The people who care about the project will find a way to contribute. That's a fundamental of the open source model. You don't like the agreement that has to be signed before your patches will be accepted? Then contribute by reviewing other people's patches, or verifying bug reports, or whatever. Onus is not on the python.org legal team to make everything work for you; it's their job to make everything work for the PSF. I haven't looked into the specifics of the agreement in detail, but I'm confident that the PSF would not demand something just for the sake of bureaucracy, so I'd trust that there's good reason for all of it. (And hey. if you don't want to sign that, you can just declare that your contributions are public domain, IIRC.) I'm sure it's very American to demand that the people in power tell you what they're doing. (Or insert any other country name there, though I think the USA is at the forefront of this.) Trouble is, open source projects simply aren't built that way. ChrisA [1] Prov 11:14 http://www.biblegateway.com/passage/?search=proverbs%2011:14 [2] Prov 15:22 http://www.biblegateway.com/passage/?search=proverbs%2015:22 [3] Prov 24:6 http://www.biblegateway.com/passage/?search=proverbs%2024:6

You want to know what's going on? Get involved. Then you'll know
+1. It's odd to complain about the project's organization and processes when you haven't actually had any real experience with either. Getting involved in some project run by other people isn't easy, but it's not really that hard either in the world of open source. On Wed, Jan 29, 2014 at 11:36 PM, Amber Yust <amber.yust@gmail.com> wrote:

On Thu, Jan 30, 2014 at 2:52 AM, Haoyi Li <haoyi.sg@gmail.com> wrote:
I first met that concept with community groups, rather than open source projects, but the result is similar. There were people who desperately wanted to be in that "inner circle" of people who knew, a year in advance, which Gilbert & Sullivan operas were going to be performed, and who'd be directing them, and who would be playing which roles, and so on. It's all announced sooner or later, but for some people, they'd really rather it be "sooner" than "later". Well, that's easily solved. Serve on the society's committee - then you know what's happening, because you're helping to make it happen. And if you're happy with a lesser advantage from lesser work, just swing by and help us with our mail-out. You get to read the info we're sending before we send it out... because you're helping us to send it out. In one stroke, you call the bluff of anyone who just wanted handouts of information, satisfy the desires of those who really care, and maybe even get some extra help running the (all-volunteer) organization. I call that a win! :) ChrisA

On Wed, Jan 29, 2014 at 6:52 PM, Haoyi Li <haoyi.sg@gmail.com> wrote:
I know that my experience is nothing compared to other people, and therefore I am even more interested to get feedback from people, deeply involved in the organization and processes, about good and bad things in the original idea of "Iterative Development" presented in the first thread message under this subject.

On Jan 28, 2014, at 23:44, anatoly techtonik <techtonik@gmail.com> wrote:
Yet another idea that some of you will find strange.
You do realize that Python is an open source project? And that the only people who work on it full time are the ones being paid by some organization that generally has its own priorities?

On Wed, Jan 29, 2014 at 11:57 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
Yes, captain. However, I fail to see why to ask the question. If you're saying that open source projects can't have any kind of methodology to save time and coordinate efforts more efficiently, then I have to disagree with you. Example from good old times of 2011 http://scons.org/wiki/BugParty I am certain there other open source projects with similar processes.
And that the only people who work on it full time are the ones being paid by some organization that generally has its own priorities?
You don't need to work full time to participate in two week cycle. As I answered to Ethan, it is not development cycle time. It is just ordinary two weeks time. You choose what you can do in these two week and do this. You may find that you have more time than you've planned during this time, so you can see who is working on what and help them (if possible).

On Wed, Jan 29, 2014 at 7:27 PM, Chris Angelico <rosuav@gmail.com> wrote:
More fun with collaboration. For some people it is not fun to grok the bugs they don't personally need to be solved. Sometimes because of complexity of the problem, but helping some else may be fun. Current bug tracker doesn't show: 1. what is important for people who think like you are 2. what is the current development focus So you can not plan how to spend your time more effectively and how to help with development.
Please explain to us the benefits of the Agile model, as they apply to a loose collaboration.
As I said, there is no single Agile model. Model can be agile (adapting, willing to change, flexible), natural or rigid. In rigid model you don't have choice. Take the bug, commit, release. In natural model you may have additional and optional steps. In agile model, you have a feedback loop that allows to estimate how good the model actually is and experiment with it to see if it can be better.

On 30/01/2014 12:52, anatoly techtonik wrote:
So you can not plan how to spend your time more effectively and how to help with development.
Core dev time could be used more effectively if they weren't sidetracked by non-issues e.g. blithering idiots who keep reopening issues on the bug tracker. I won't mention any names. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On 31 Jan 2014 04:17, "Mark Lawrence" <breamoreboy@yahoo.co.uk> wrote:
by non-issues e.g. blithering idiots who keep reopening issues on the bug tracker. I won't mention any names. Mark, as annoying as Anatoly is, this is still a violation of the list code of conduct. If you find him too irritating to allow you to maintain civility on the core lists when dealing with him, set your mail client to ignore his messages (that's what most of the core devs have been doing for quite some time). Anatoly already got himself banned from bugs.python.org with his antics, and his moderation flag is set on all the core mailing lists. At the rate he is going, he is not encouraging anyone to reconsider either decision, and it's still possible for that moderation flag to be upgraded to an outright ban from the mailing lists if the mods decide it would be appropriate. Regards, Nick.
-- My fellow Pythonistas, ask not what our language can do for you, ask what
you can do for our language.

On 31/01/2014 11:41, Nick Coghlan wrote:
Who says I was getting at Anotoly? Unless the English language has changed without my knowledge, you'll find that "idiots" and "names" are plural and not singular. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 2:13 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
That's a perfectly valid argument, in the same way that this is perfectly valid code: # utils.py import math math.pi = 3.159 SECONDS_PER_MINUTE = 60 def minsec(sec): global SECONDS_PER_MINUTE SECONDS_PER_MINUTE+=2 return sec//SECONDS_PER_MINUTE, sec%SECONDS_PER_MINUTE def format_time(sec): min,sec = minsec(sec) return "%02d:%02d"%(sec,min) It's all perfectly legal Python, but it breaks all sorts of conventions, and you know it. In the context of this thread, it was obvious to everyone what you were saying, and hiding behind the technicality of plurality doesn't help you. Do please be honest with yourself and us. ChrisA

On 31/01/2014 15:26, Chris Angelico wrote:
Asperger Syndrome sufferers are always honest. Sadly I find it a major weakness that I have to live with. We also take things literally and write things literally. So your "obvious to everyone what you were saying" to me is clearly incorrect. Please withdraw the comment. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 2:45 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I know what it's like to live with Aspergers, I have it myself (at least, not formally diagnosed but it seems pretty likely). And I do put my foot in my mouth pretty often. But that doesn't mean that I can hide behind it as a shield when it's this obvious. You knew full well what you were saying when you said you wouldn't mention any names. Now, I do enjoy a good upper-class British insult-fest. That's a major part of what makes quite a few British comedies work - the utterly courteous, yet bitingly cutting, wit, barb, and counter-barb. The tenor explains to the soprano that he was just disguised as a member of the band, that he's really a much more important person, and she says that she knew he was in disguise the minute she heard him play. But when that wit is wielded inappropriately, the proper response is a graceful apology or retraction... or, if circumstances demand, a barbed retraction ("I implied in the House last week that the Hon Member had the intelligence of a stuffed egg. This was inappropriate, and I formally apologize for and retract this analogy. My breakfast egg today deserved no less."), but you have to be VERY sure of your ground before you take that option - claiming Aspergers is not sufficient. This'll probably sidetrack everyone terribly (for which I'm not sure if I apologize; it might be a good thing for some people to get stuck in TVTropes for a while) but this write-up about Asperger Syndrome gives an excellent comment: http://tvtropes.org/pmwiki/pmwiki.php/UsefulNotes/AspergerSyndrome """ Most genuine Aspies don't see Aspergers as a 'Get Out Of Jerk Ass Free' card, just an explanation. If somebody offends you, then tells you they have Asperger Syndrome and that's why they offended you, you can generally tell if this is true by a simple observation - If the admittance is followed (or preceded) by a genuine apology, it may be true. If it's followed by the expectation that you should now apologise to them for being offended, they're probably just jerks. """ I'll let that speak for itself. ChrisA

On 31/01/2014 16:15, Chris Angelico wrote:
Once again I most certainly *DID NOT*. I knew full well what I was writing. I quite deliberately used plurals for that very purpose. Please in future stick to your bible bashing as you clearly know far more about that than you know about Asperger, with myself having a formal diagnosis. And please don't bother to withdraw your comment now or apologise, I wouldn't accept either as being in any way, shape or form genuine. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 4:32 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I wouldn't withdraw my comment, because I still stand by it. If you genuinely meant no specifics, then when someone pointed out how they interpreted your statement, you would have apologized and made a correction: "I didn't mean anyone in particular, I meant the way there've been 50 issues reopened unnecessarily by 30 different people lately", or something. But that wouldn't be true, would it? You really did mean Anatoly, and that's why you said what you did. Believe you me, I know more than you think I do. Think of Emma from "Once Upon A Time" if you like - a strong ability to detect lying, based on a metric ton of experience with it. ChrisA

On Sat, Feb 01, 2014 at 04:42:04AM +1100, Chris Angelico wrote:
Hi all, this is getting rather meta, in a profoundly unproductive way. Can we stick to software development, Python, and non-personal-or-plural insults, please? thanks, --titus [ <-- wearing moderator hat ] -- C. Titus Brown, ctb@msu.edu

On 31/01/2014 16:28, Ethan Furman wrote:
Your opinion, clearly not mine. Further I don't discuss anything that starts on a Python mailing list with people offline as I don't believe in discussing things behind other people's backs. As for wasting developer time how much has been wasted by various people who've routinely insulted Python and by continuance its developers, and yet they're still allowed to spew their nonsense and get away with it? Yet again we're into the dual standards that annoy me so much, yet for speaking my mind I'm the one in the wrong. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Sat, Feb 1, 2014 at 4:28 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
No, you're not in the wrong for speaking your mind. You're declared to be (or treated as) in the wrong based on an objective analysis of the content and style of your posts. Anatoly is at fault too, but your issues are almost completely tangential to his. They just happen to be in the same thread. Now please, stop talking. Trust me, you're only digging yourself further into a hole. This discussion is way way off topic, and I'm becoming painfully aware that I've said way too much already myself. ChrisA

Am 31.01.2014 18:28, schrieb Mark Lawrence:
Yet again we're into the dual standards that annoy me so much, yet for speaking my mind I'm the one in the wrong.
Would you like to show me a recent post from Anatoly with the word "idiot" in it? Oh right, there isn't one, because he's moderated. Double standards? Georg

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
Asperger Syndrome sufferers are always honest. Sadly I find it a major weakness that I have to live with.
That's unfortunate. Please don't impose it on others too. -- \ “When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney

On 29/01/2014 07:44, anatoly techtonik wrote:
Yet another idea that some of you will find strange.
Instead of coming up with ideas, why not sign the contributors' agreement and come up with code that people can actually use? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Wed, Jan 29, 2014 at 12:29 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
replied to python-legal-sig https://mail.python.org/pipermail/python-legal-sig/2014-January/000070.html

On Wed, Jan 29, 2014 at 3:08 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Basically, you refuse to sign a contributor agreement, but insist on blaming the PSF for that. Your position is simply unreasonable: You demand that the PSF should either stop demanding a contributor agreement, accept your own personal version of it, or spend a lot of time and energy attempting to explain it to you. You blame the PSF of being a needlessly bureaucratic political body which is giving you a hard time just because it can or because it doesn't care; whatever you may think, that is the opposite of the truth. Furthermore, since you continue to choose to phrase your arguments aggressively and offensively, how can you expect anyone to consider your proposals?? Regarding the contributor agreement, please spend your time and energy understanding it, instead of arguing about it here and blaming other people. Otherwise, stop pestering people about it. What you demand regarding the contributor agreement is not going to happen, period. If you actually care about Python, find a way to contribute helpfully! Even if you believe that we are the ones being stubborn and unhelpful, it is up to you to find a way to work with us productively. For example, I am sure you have noticed that few of your ideas posted here have been helpful in any way, if any at all. I do believe that you think these are good ideas, but surely you must see that nothing good results from your posting them to this list. As it is, you have been harming the development of Python considerably for many months by pestering people on various mailing lists. If you want to help, you must change your behavior! - Tal

On 1/29/2014 2:44 AM, anatoly techtonik wrote:
This is more or less what we do now on an issue by issue basis. At a higher level, releases for the 'next' version already come out at 2 or 3 week intervals from a0 to final. At a higher level, we already have plans for 3.5 that we will start on as soon as 3.4.0 is out or after PyCon. -- Terry Jan Reedy

On Wed, Jan 29, 2014 at 12:47 PM, Terry Reedy <tjreedy@udel.edu> wrote:
It is quite obvious from outside that Python has some kind of process, but it is quite hard to sync to it for people from outside, because it is not open - is not completely clear how the planning is made, which tasks are available for current sprint, what you can help with and how to track the progress.

I haven't been following this thread very closely, but I have to disagree with you here, Anatoly. On Thu, Jan 30, 2014 at 5:24 AM, anatoly techtonik <techtonik@gmail.com> wrote:
It is quite obvious from outside that Python has some kind of process,
Which is well documented in several places. It can be tricky to always find all of those places, but anyone who is interested can ask, and will be quickly shown where to look.
but it is quite hard to sync to it for people from outside,
I'm not sure what you mean here. Every contributor starts from "outside" of Python. I found no difficulty in getting started when I did, and I've seen several people start contributing successfully since then. It would be very hard to go from nothing to suddenly contributing huge patches to the innermost details of Python at a rapid pace, but that's not really what people (especially people new to open source development, like I was) should be doing anyway. Start slow and small, build from there, and it's an easy and painless process.
because it is not open
Here I must disagree emphatically. My entire Python experience shows me that everything about Python is as open as possible. If you want to know something, look for it. If you can't find it, ask for it. If you can't be shown where it is, somebody (even yourself) will write it down somewhere so the next person looking can find it.
- is not completely clear how the planning is made,
I'm not sure what you mean here, what planning? Anything that could be construed as "planning" is done via the PEP process, which is well documented in PEP 1.
which tasks are available for current sprint, what you can help with and how to track the progress.
This is the very definition of a bug tracker, and Python's is quite good for all of this. There could stand to be some upkeep done on some of the older issues: it would be good for an impartial person to pick through and see whether an issue is still a problem, update any patches to apply to current branches, manage the 'easy' tag, add the proper people to the nosy list, etc. This kind of thing would be a great place for someone to contribute. Honestly, just bringing all tracker issues up to date would be a worthwhile sprint task in my opinion. -- Zach

Am 30.01.2014 17:17, schrieb Zachary Ware:
Nowadays the development process is really well documented in the devguide. If anything is still not in there, that should be fixed.
That's the key: *ask* for it. Do not rant that you didn't find something, complain that it wasn't in some random place you expected it, and then not accept help and hints from people that weren't put off replying you in the first place.
We have tried quite a few times to make it clear to Anatoly that there is no "planning" made apart from what you can read about in PEPs and mailing lists. Apparently he thinks there's a secret agenda, when in reality there often is no (shared) agenda at all -- that's in the nature of an open source project. Of course individual developers may have private agendas.
Few people have tried that because it's such a thankless task, but there was definitely progress. cheers, Georg

On Thu, Jan 30, 2014 at 11:15 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Let's pinpoint the conflicting point first - "nature of an open source" - s/a/the/ As I already pointed out, many open source project have planning, and before expanding the idea, let's say that I never had any conspiracy theory behind planning of Python development - I perfectly realize how the chaotic the process is, but that's not clear from outside, and what I am trying to say that not having any visible planning strategy (chaos is a strategy) is bad for any organized effort and more importantly - for an effort to organize. There is a big potential for self-organizing teams in Python community, but that's just didn't happen, because these team can't hold together. They can be organized around bugs (as in bug tracker), issues (as a "problem"), components (stdlib modules), releases (as it works now), tools (independent of core development at all), ideas (as we see in this thread). But to hold on, people from different time zones, cultures, need to sync. Iteration has one awesome and distinctive property - any iteration stripped of all the feature- creeped stuff is just a sync point in time. So, sync point is "subject, place and time". I tried to start with place for pydotorg (see thread few years ago), subject (attempt to split things by module in tracker) - https://bitbucket.org/techtonik/python-stdlib - good indicator of poor development of my skills and now I came to conclusion that the only thing that matters is time. Sync points are important, because they allow a project to be inclusive for people who are not interested in Python development at all, but may want to join later, because they want to make a change. You don't force people to read papers, but let them see hot it works. It is also more entertaining for the brain to watch the real thing and hack on ideas how to make the whole entrypoint more exciting. I can't name any reason why anyone should be excited with Python core developer when faced with a dusty tome of paperwork of ancient contributing wisdom written in largely uncommon English language.
Make it thankful. Make 'implementing a Twisted Highscore for b.p.o' a goal of the next iteration and let people contributions flow. If truck can not pass through gate, somebody get out and lift it. If chaotic effort is ineffective, then coordinated effort can help. There could be coordinator for the one or two iterations, but it can be possible for technology to help with it in the long run if it is worthy. -- anatoly t.
participants (16)
-
Amber Yust
-
anatoly techtonik
-
Andrew Barnert
-
Ben Finney
-
C. Titus Brown
-
Chris Angelico
-
Ethan Furman
-
Georg Brandl
-
Haoyi Li
-
Mark Lawrence
-
Nick Coghlan
-
Oleg Broytman
-
Stephen J. Turnbull
-
Tal Einat
-
Terry Reedy
-
Zachary Ware