On Thu, Jan 30, 2014 at 11:15 PM, Georg Brandl <g.brandl@gmx.net> wrote:
>>> - 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.

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/