On Thu, Jan 30, 2014 at 11:15 PM, Georg Brandl
- 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.
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.
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.
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.
Few people have tried that because it's such a thankless task, but there was definitely progress.
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.