The this-needs-to-be-in-django angst

[mrts-2]

Let me suggest that there are many who have at
times felt frustrated how contributions or
suggestions are managed in Django. Some of them
seem to have walked away or just don't participate
in discussions any longer. The same applies to
several other large open source projects, the
Linux kernel and it's mailing list being a prime
example.

However, the frustration was mostly justified
*before* Django 1.0 came out and the the
semi-official DVCS mirrors took off. It was hard
to keep patches updated - the internal APIs were
in flux and Subversion was and is not flexible
enough (even with svnmerge.py) to make branchy
development painless. The frustration stemmed from
too much change and no tools for managing it.

In my opinion, neither of the problems apply as of
now. Maintaining your own branches on GitHub or
BitBucket off the corresponding Django SVN mirrors
is easy and effortless, so it's time to put the
grudges behind and happily fork and branch Django
on the DVCS sites whenever there's a need for
something missing from or broken in the official
trunk - and, what's perhaps even more important,
give back by shepherding the corresponding tickets
in Django trac (keeping them up to date, improving
them according to other's suggestions etc).

"Relax," as CouchDB puts it :)

Best,
Mart Sõmermaa
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[mrts-2]

(Inspired by Yuri Baburov's criticism and RKM's response.)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[buriy]

Hi Mart,

actually, you are half right. Fork & go.

Still the main reason I wrote wasn't recognized.

Total anarchy in Django team.

Core developers don't agree with each other on who will respond on
what kind of messages, what part of Django contributions is under
their maintenance.
Moreover, new contributors are considered the least important
creatures in the world!!!

The more you do, the more attention your suggestions receive. But for
your first enhancement to be approved, you'll have to wait a year!
Ingenious!

Half of feature expressed in list is never replied by core developers
with their opinion or explanations.
Half of feature requests in Trac got misunderstood or not replied or
reviewed within 1 year.

Imagine your recipients email boxes silently drops 50% of your
traffic, and recipients don't response on 50% of last 50% within first
year of waiting, after their receive confirmation, because they can't
decide who can do what responses and they just don't have time.
Will you succeed? Would you ever try?

And a bit more about "fork & go" + "better maintenance":

Say, if django team will not agree with JQuery merge into admin app,
I'll fork django.contrib.admin as a separate project.
It will increase development speed in about 3 times, maybe more.
I still have much more other things to do it right now, but someone
else might think as a brilliant idea to do that right now ;)
I think some other modules can also be moved to separate repos, making
someone (maybe out of django team) their sole maintainer, or using
distributed model, and thus enhancing development speed in 3-100
times.

So I hope django team will analyze their management structure
critically and at least set responsible persons (maintainers) for
different parts, to ensure there are no items nobody wants to
listen/answer on feature request.
I strongly believe there should be no attempts to contribute that
"didn't attract our attention".

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: buriy@...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

Hi Yuri, Mart --

I feel that I need to make it clear that I'm not ignoring you, or this
conversation. However, the tone is so hostile and unprofessional that
it'd be a waste of my time to try to engage, so I'm simply going to
stay out.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Tue, Oct 20, 2009 at 10:23 PM, Jacob Kaplan-Moss <jacob@...> wrote:
>
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.

Likewise for myself.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[buriy]

On Tue, Oct 20, 2009 at 9:23 PM, Jacob Kaplan-Moss <jacob@...> wrote:
>
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.

Hi Jacob,

well, let's go further,

how would you reformulate this in friendly and professional tone so
this can be discussed?

--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: buriy@...

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[mrts-2]

Jacob, I'm afraid you totally misunderstood me.
My message was intended to encourage people to
scratch their own itches more now that it's so
much easier -- and, of course, give back --
instead of grumbling on the mailing list.

I fail to see how can "so it's time to put the
grudges behind and happily fork and branch Django
on the DVCS sites whenever there's a need for
something missing from or broken in the official
trunk - and, what's perhaps even more important,
give back by shepherding the corresponding tickets
in Django trac" considered to be hostile.

Baffled,
MS

P.S. I've worked on [1] exactly that way, is that
considered to be hostile?! If so, please elaborate.

[1] http://code.djangoproject.com/ticket/7028

On Oct 20, 5:23 pm, Jacob Kaplan-Moss <ja...@...> wrote:
> Hi Yuri, Mart --
>
> I feel that I need to make it clear that I'm not ignoring you, or this
> conversation. However, the tone is so hostile and unprofessional that
> it'd be a waste of my time to try to engage, so I'm simply going to
> stay out.
>
> Jacob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Tue, Oct 20, 2009 at 10:52 AM, mrts <mrts.pydev@...> wrote:
> Jacob, I'm afraid you totally misunderstood me.
> My message was intended to encourage people to
> scratch their own itches more now that it's so
> much easier -- and, of course, give back --
> instead of grumbling on the mailing list.

Yup, that's very constructive advice, and my apologies: I was mostly
referring to Yuri's message when I talked about tone. Although you're
both talking about forks, you're doing it in a much more constructive
way.

You have to understand that historically the fork as been the nuclear
option in open source. Threatening to fork the code is roughly the
equivalent of saying "screw you guys." Forks diverge quickly, and
reconciliation becomes difficult, and so it's hard to feel any desire
to engage.

I understand you're saying something different here -- DVCSes have, to
a limited degree, changed the story when it comes to forks. Rather,
it's enabled a middle ground -- distributed branches -- that allow
many of the benefits of a fork without all the heartache.

What's frustrating, though, is hearing that you have a problem with
our workflow without any concrete suggestions to improve it or offers
of assistance. There's a general theme underlying most of this "angst"
(as you call it): the tone implies that you're somehow entitled to our
(core developers) time and energy, when we're just as stressed,
harried, and busy as you.

We're *volunteers*. We work on Django because we *want* to, because it
scratches our own itches. This sense of entitlement to our time and
energy is rude and offensive. If *anything* gets done, it's because
someone volunteers to do it. If things aren't getting done, volunteer.

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Tue, Oct 20, 2009 at 9:35 AM, Yuri Baburov <burchik@...> wrote:
> how would you reformulate this in friendly and professional tone so
> this can be discussed?

I don't have time to teach you how to communicate professionally.

Reading your message first makes me feel angry, then dismayed. It
makes me feel as if all the hard work I've put into Django doesn't
matter. It makes me think there's really no point in doing any further
work, because someone will just come along and crap all over it again.

You need to empathize with how someone's going to feel reading your
message. Until you do, people are going to ignore you at best, and get
into a flame war at worst. This is your problem, not mine.

But since good communication is a two-way street, I'll give you a
hand. Why don't you try making some concrete, actionable suggestions
about how you'd like to volunteer to improve things? If you see
something broken, how about starting by offering to fix it?

Jacob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

On Tue, Oct 20, 2009 at 8:44 AM, Yuri Baburov <burchik@...> wrote:
> Moreover, new contributors are considered the least important
> creatures in the world!!!

As they say on Wikipedia, "[citation needed]". This list grows with
every new release:

http://code.djangoproject.com/browser/django/trunk/AUTHORS#L27

> Half of feature requests in Trac got misunderstood or not replied or
> reviewed within 1 year.

The tickets currently open in Trac represent approximately 14.5% of
all tickets ever opened. About 15% of all open tickets are currently
at the "unreviewed" stage.

These numbers suggest that you are, at the very least, exaggerating
quite a bit. I'm sure you can and will cherry-pick a few tickets to
try to show as examples of why you're right, but on the whole the
statistics aren't in your favor here.

That doesn't mean we can't do better, of course (we could always do
better), but it does mean that your claims need to be taken with a
pretty big grain of salt.

> So I hope django team will analyze their management structure
> critically and at least set responsible persons (maintainers) for
> different parts, to ensure there are no items nobody wants to
> listen/answer on feature request.

You seem to think that any input anyone makes gives them an automatic
claim to the time and attention of a committer. I think that's a
rather strange idea, because I already don't have enough hours in the
day to get the stuff done that I'm doing right now, and that's not
exactly a unique situation to be in. This is the point where,
traditionally, someone steps up and says we should just bring in a
bunch of new committers -- then there'd be plenty of people with
plenty of time! -- but it's still not going to get what you seem to
want, since there'll always be times when nobody can spare much
attention, or requests that nobody particularly feels like dealing
with immediately (and, on the whole, I think it's been a very good
thing for Django to be so stingy with the commit bits).


--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Vinay Sajip]

On Oct 20, 5:26 pm, Jacob Kaplan-Moss <ja...@...> wrote:
> I don't have time to teach you how to communicate professionally.

I don't presume to speak for Yuri (or anyone else) but I think it's
not unreasonable that some allowance be given in situations where
miscommunication of tone can happen because of cultural differences
or differing levels of facility with language, or sheer lack of time
used in crafting a communication. It's very understandable if you and
Russ want to turn your backs because of a communication which appears
abrasive - we're all human, after all - but might that not be throwing
the baby out with the bath water? Unless someone is obviously
trolling, and if it appears that they want to improve Django in some
way (even if their way seems weird or doesn't align with what the core
devs want) then it's perhaps worth giving the benefit of the doubt,
and important not to discount a message just because of the tone in
which it's conveyed.

> Reading your message first makes me feel angry, then dismayed. It
> makes me feel as if all the hard work I've put into Django doesn't
> matter. It makes me think there's really no point in doing any further
> work, because someone will just come along and crap all over it again.

Please don't feel like that - it's very clear that lots of people
value Django enormously, which means they value the hard work everyone
has put in to get it to where it is. And I'm not sure if you're
talking about any other post than Yuri's in this thread, but that
appeared to me to arise from frustrations with the process rather than
attributing any particular criticism of the software.

> You need to empathize with how someone's going to feel reading your
> message. Until you do, people are going to ignore you at best, and get
> into a flame war at worst. This is your problem, not mine.

Well, if a good idea gets ignored by the committers because it was
suggested in a snotty way, perhaps that's not *just* a problem for the
suggester.

> But since good communication is a two-way street, I'll give you a
> hand. Why don't you try making some concrete, actionable suggestions
> about how you'd like to volunteer to improve things? If you see
> something broken, how about starting by offering to fix it?

Perhaps I've misunderstood, but "offering to fix it" for a non-
committer means "making a suggestion about how to fix it". Sometimes
that involves submitting a patch, and other times (because the problem
may be clear but the solution isn't) it means trying to engage in a
discussion about "how to fix it". A discussion isn't a monologue, is
it? And I know that Django committers are all volunteers, but aren't
many of the non-committers who make suggestions volunteers too? You
mentioned empathizing, so put yourself for a minute in the position of
non-committers who want to suggest how to improve something. If their
suggestions seem to disappear into the ether, and are *apparently*
ignored by the core devs, then what would constitute reactions from
the suggester which are "not unreasonable"?

I've got some quotes from Yuri's post, with my comments and questions:

"... who will respond on what kind of messages, what part of Django
contributions is under their maintenance."

I have to admit, I don't know the answer to this. Is it documented
somewhere? Does it matter, in your view?

"Moreover, new contributors are considered the least important
creatures in the world!!!"

Do you disagree with this? Obviously newcomers will need to earn the
trust of the community and the committers. But perhaps a way needs to
be found of avoiding what mrts characterises as "there are many who
have at times felt frustrated how contributions or suggestions are
managed in Django. Some of them seem to have walked away or just don't
participate in discussions any longer". Or this this just a figment of
mrts' imagination?

"The more you do, the more attention your suggestions receive. But for
your first enhancement to be approved, you'll have to wait a year!"

It would seem that what the suggestion is should merit the level of
attention rather than who the suggester is, modulo the notion that
obviously old hands have greater credibility than new kids on the
block.

"Half of feature expressed in list is never replied by core developers
with their opinion or explanations. Half of feature requests in Trac
got misunderstood or not replied or
reviewed within 1 year."

"Imagine your recipients email boxes silently drops 50% of your
traffic, and recipients don't response on 50% of last 50% within first
year of waiting"

Leaving aside the exact time frames and percentages which may well be
exaggerated, do you feel that the process is working so well that no
one is justified in feeling the frustration that's obviously being
expressed?

Overall ISTM that people are expressing frustration at "being hard
done by" rather than just being ungrateful whiners. Or am I coming
across as an ungrateful whiner myself? ;-)

Regards,

Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Vinay Sajip]

On Oct 19, 4:13 pm, mrts <mrts.py...@...> wrote:
> now. Maintaining your own branches on GitHub or
> BitBucket off the corresponding Django SVN mirrors
> is easy and effortless, so it's time to put the
> grudges behind and happily fork and branch Django

It seems like the word "fork" is invested with political meaning (a
"nuclear option") so I would stick with "branch". What you're
suggesting is just what I did some time ago: My svn checkout is in a
folder '~/projects/django/upstream' which is also a DVCS repository,
and from there I create DVCS branches in sibling directories for
working on specific features: ~/projects/django/logging, ~/projects/
django/app_labels etc. I periodically merge these with the upstream
branch, which I keep up to date using 'svn up'.

While this works well for scratching my own itches, and for
experimentation, I'm not sure to what extent (if at all) it helps move
the platform forwards. If I published my branches in a public
repository (GitHub/Launchpad/BitBucket), and if people then started to
use that code, then unless I keep all those branches (with different,
independent features) updated with changes in Django trunk, and I am
very responsive to users of my code in terms of suggestions for
improvements etc. then all I've achieved is to create another version
of the code which doesn't please people, isn't known to a lot of
potential users for a variety of reasons, and perhaps becomes the
basis of someone else's branch - it sounds like there's a possibility
that a lot of time will be spent in merging, checking what different
branches do, etc. - a DVCS version of DLL hell ;-)

So, DVCSs are great for each person to maintain their own variant of
Django, but less useful for sharing our variants with the rest of the
community because each variant will (understandably) have tiny
mindshare compared with the main project.

Sometimes, that won't matter because we're in complete control of what
variant of Django gets installed on a particular site. At other times,
we want to take advantage of a standard Django that our customers have
already got and are invested in, where there's no room for our
branched Django with those must-have (in our opinion) features. Then,
having our own branched version with our favourite bells and whistles
will be no good to us.

Am I making sense?

Regards,

Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Vinay Sajip]

On Oct 20, 5:46 pm, James Bennett <ubernost...@...> wrote:
> The tickets currently open in Trac represent approximately 14.5% of
> all tickets ever opened. About 15% of all open tickets are currently
> at the "unreviewed" stage.
>
> These numbers suggest that you are, at the very least, exaggerating
> quite a bit. I'm sure you can and will cherry-pick a few tickets to
> try to show as examples of why you're right, but on the whole the
> statistics aren't in your favor here.

Thanks for taking the trouble to look at the numbers. Exaggeration
doesn't help anyone, but I think it's just born out of a sense of
frustration in this case.

> That doesn't mean we can't do better, of course (we could always do
> better), but it does mean that your claims need to be taken with a
> pretty big grain of salt.

I would say, leave the specific claims to one side. Isn't it
reasonable to see whether the frustration being expressed is only
being felt by a very small number of individuals, or whether there may
be an actual issue to address?

> You seem to think that any input anyone makes gives them an automatic
> claim to the time and attention of a committer. I think that's a
> rather strange idea, because I already don't have enough hours in the
> day to get the stuff done that I'm doing right now, and that's not
> exactly a unique situation to be in. This is the point where,

No one has an *automatic* claim on the time and attention of a
committer, perhaps not even another committer. However, what does the
word "community" mean to you? Lots of different things, perhaps, just
as it does for me - but for me, one of those things is a sense that
there is *some*, that is to say *non-zero*, level of *mutual*
obligation between members of a community. If you're walking a few
steps behind a complete stranger as you both walk through a doorway,
that person has perhaps no obligation to take the time and attention
to hold the door open for you. Sometimes, they don't. Has that ever
happened to you? What did you feel? When it happens to me, I confess I
feel a little irritated. Am I alone in this? And sometimes the
stranger turns back and says sorry for not having held the door open
for me - what makes them do that? If they think they owe me absolutely
nothing, they wouldn't feel the need to apologize. And what would you
feel if the other person wasn't a complete stranger, but an
acquaintance? Someone you've seen being perfectly nice and considerate
to other people?

> traditionally, someone steps up and says we should just bring in a
> bunch of new committers -- then there'd be plenty of people with
> plenty of time! -- but it's still not going to get what you seem to
> want, since there'll always be times when nobody can spare much
> attention, or requests that nobody particularly feels like dealing
> with immediately (and, on the whole, I think it's been a very good
> thing for Django to be so stingy with the commit bits).

It's all a question of balance, isn't it? Django isn't unique in
having to find that balance. Other open source projects have the same
tensions. Your phrase "a bunch of new committers" almost implies that
you think people are expecting you to bring them in off the street,
rent-a-crowd style! You know it isn't so. And clearly, the list of
Django committers *has* grown over time. We appreciate you're doing
the best you can. As Django is a high-profile project with lots of
goodness and loved by many, it's inevitable that people want to
contribute, and make it even better - there being many values of
better ;-). There are bottlenecks in the process (which I think the
core team acknowledges, but please say so if that's not the case), and
this leads to frustration. There's no easy answer, but thank you for
the considered, non-petulant tone of your response.

Best regards,

Vinay Sajip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[mrts-2]

On Oct 20, 7:19 pm, Jacob Kaplan-Moss <ja...@...> wrote:
> What's frustrating, though, is hearing that you have a
> problem with our workflow without any concrete suggestions
> to improve it or offers of assistance. There's a general
> theme underlying most of this "angst" (as you call it):
> the tone implies that you're somehow entitled to our (core
> developers) time and energy, when we're just as stressed,
> harried, and busy as you.

That's perfectly understandable and well respected. When I
referred to "frustration on how contributions or suggestions
are managed in Django" and later on to the Linux kernel and
its mailing list, I intended to suggest that to an extent,
frustration in the community is inevitable - and only then
demonstrate the Noble Path Out Of It, for a dramatic effect
of sorts :).

As for assistance - let me humbly point out that I've
written
http://code.djangoproject.com/wiki/CollaborateOnGithub
precisely for helping people to overcome their git-fear and
get a feel how easy maintaining a patch is if done properly.

It's also inevitable that the core devs are stressed and
busy, torn between real-life needs and the immense energy
required to steer a community full of both excellent and -
luckily to a much lesser extent - misguided ideas. That
stress does sometimes (albeit rarely) result in loss of
empathy and gentleness. This is human, understandable and
happens in all open source projects. No big deal, but I do
share Vinay's sentiment regarding the door metaphor.
http://www.ubuntu.com/community/conduct is a good read for
any community manager.

I generally agree that the current trac + mailing list
process is mostly fine (especially if coupled with fleshing
out ideas in the wiki that seems to be becoming standard
practice now) and believe I'm in no position to suggest
improvements - but being invited to it, let me share a few
nevertheless (directly borrowed from Debian/Ubuntu, Linux
kernel and Unladen Swallow communities).

Django Bug Days
---------------

At regular intervals, say twice a month on Saturdays,
set aside 2-3 hours for IRC-based bug hunting sprints.

Devs list tickets that they want people to work on and
people are free to suggest their own.  Work is done over
longer periods, but the bug days provide an occasion to
get feedback from the devs.

The patches will perhaps not be integrated into SVN but to a
branch on a DVCS (see the next suggestion).

Added benefit: if nobody shows up, they have no right to
grumble on the mailing list :).

A DVCS mm-tree
--------------

Quoting
http://en.wikipedia.org/wiki/Andrew_Morton_(computer_programmer)

"He currently maintains a patchset known as the mm-tree,
which contains not yet sufficiently tested patches that
might later be accepted into the official Linux tree."

I.e. there would be a DVCS branch (avoiding the f-word now)
maintained either by a core dev or a designated community
member that would accept patches more liberally -- but still
only patches that are up to Django standards, i.e. tests and
docs remain mandatory.

This will probably be most effective in context of the bug
days, otherwise the management overhead may be too big.

Also, that branch would have a few buildbots running tests
on it.

Code review
-----------

Code reviews are super useful, because, in the end of the
day, we communicate in code.

I have no idea if integrating a code review tool with trac
is feasible, so if this looks attractive, the only realistic
way to adopt it would be a social-coding-site-centric
process - patches remain in trac tickets, but it's highly
recommended to maintain corresponding branches in GitHub or
BitBucket, so that community members can write code reviews
there.

Best,
Mart Sõmermaa

P.S. I won't re-animate the ticket classification argument
that created a lot of unintended controversy last year, but
I personally think that divide and conquer is the only way
to manage the 1700+ open lot.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Thu, Oct 22, 2009 at 3:22 AM, mrts <mrts.pydev@...> wrote:
>
> On Oct 20, 7:19 pm, Jacob Kaplan-Moss <ja...@...> wrote:
>
> Django Bug Days
> ---------------
>
> At regular intervals, say twice a month on Saturdays,
> set aside 2-3 hours for IRC-based bug hunting sprints.

Yes, we should have more regular sprints. However, you need to
remember that organizing things takes time, and time is one of the
things that the core team is seriously lacking.

That said, Jeremy Dunck has recently expressed an interested in
helping to coordinate organization of a regular sprint schedule. If
you want to help out organizing these (including finding a time slot
that is convenient for the relevant timezones), you might want to get
in touch with him - or alternatively, just go ahead and organize them
yourself. You don't need core blessing to organize a bug-squashing
party. If you want to confirm the availability of the core for such an
event, just ask.

Talk of a "once every two weeks" schedule is possibly a little
optimistic if you expect *all* the core developers to turn up every
time, but if you are just talking about setting up a regular time and
place where people will know that there will be some bug-catching fun
in IRC, that sounds like a great idea.

Build it and they will come. :-)

> A DVCS mm-tree
> --------------

Let me tell you a store about three people named Everybody, Anybody,
Somebody and Nobody.

There was a job to be done. Everybody agreed it should be done.
Anybody could have done it. Somebody should have done it. Nobody
actually did it. :-)

An mm-style tree could certainly be a useful resource for the core.
Merging trunk-ready patches from a git/hg mm-branch would certainly be
easier than doing the Trac patch dance.

However:

 1) Someone actually needs to maintain the tree. Don't underestimate
the time required to do this - it will be just as time-consuming as
maintaining the trunk, and the core can't compel anyone to do
anything.
 2) Someone needs to keep maintaining the tree over a long period of
time. It's not much help if the mm-tree exists for a week of
enthusiasm, then dies out.
 3) The Someone in question needs to have the right skills and taste.
It's no good having an mm-tree that integrates patches that the core
consistently rejects.
 4) I can almost guarantee you that if Someone actually met the first
three criteria, they would be given the commit bit.

It's no good saying "someone should". Someone actually needs to do it.
If you want to do it, go right ahead.

Again - build it and they will come.

> Code review
> -----------
>
> Code reviews are super useful, because, in the end of the
> day, we communicate in code.
>
> I have no idea if integrating a code review tool with trac
> is feasible, so if this looks attractive, the only realistic
> way to adopt it would be a social-coding-site-centric
> process - patches remain in trac tickets, but it's highly
> recommended to maintain corresponding branches in GitHub or
> BitBucket, so that community members can write code reviews
> there.

Personally, I'm not convinced that a code review tool will actually
improve anything - it strikes me as a technical solution to something
that is actually a social problem.

The social problem is that there are people that I trust, and the
opinions of those people are very important when I review a patch.
Code reviews are useful - when they come from someone you trust. A
code review from John Q. Random Hacker is just as likely to be noise
as useful feedback.

The process of getting my (or anyones) trust is a process of accretion
over time - I trust X because I've seen their contributions over
several years; I don't trust Y because they have consistently shown
poor taste; I don't know if I trust Z because I haven't seen enough of
their work. This trust isn't a simple algorithm - it's a personal
perception issue. A small number of significant patches could do more
to influence trust than a long history of less significant patches.

There might be some potential for tool support in this area - but it
certainly isn't as simple as just adopting a code review tool.

In summary, your mail (and, really, this entire thread) has contained
a lot of "the core should", or "someone should". The source of my
(and, I suspect Jacob's) frustration is that these comments aren't
especially helpful. We know all the things that we *could* do - what
we don't have is the time to deliver on all these ideas.

On the other hand, saying "I am going to" is extraordinarily helpful.
Saying "I already have" is even better. You don't need the core's
blessing to do anything. Allow me to assure you that if you develop
and maintain a resource that is useful, people - including the core -
will use it. The hard part has never been coming up with ideas. The
hard part is delivering.

Build it, and they will come.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[James Bennett]

On Wed, Oct 21, 2009 at 7:36 PM, Russell Keith-Magee
<freakboy3742@...> wrote:
> Let me tell you a store about three people named Everybody, Anybody,
> Somebody and Nobody.

Four! The four people in this story are...



--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Oct 21, 2009, at 7:48 PM, James Bennett <ubernostrum@...>  
wrote:

> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of  
> correct."

Very fitting.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Thu, Oct 22, 2009 at 8:48 AM, James Bennett <ubernostrum@...> wrote:
>
> On Wed, Oct 21, 2009 at 7:36 PM, Russell Keith-Magee
> <freakboy3742@...> wrote:
>> Let me tell you a store about three people named Everybody, Anybody,
>> Somebody and Nobody.
>
> Four! The four people in this story are...

erm... ahh... Nobody isn't a person?

:-)

Russ %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Paul McLanahan]

On Wed, Oct 21, 2009 at 8:57 PM, Russell Keith-Magee
<freakboy3742@...> wrote:

>
> On Thu, Oct 22, 2009 at 8:48 AM, James Bennett <ubernostrum@...> wrote:
>>
>> On Wed, Oct 21, 2009 at 7:36 PM, Russell Keith-Magee
>> <freakboy3742@...> wrote:
>>> Let me tell you a store about three people named Everybody, Anybody,
>>> Somebody and Nobody.
>>
>> Four! The four people in this story are...
>
> erm... ahh... Nobody isn't a person?

Somebody should really get on that then. Everything would be done if
Nobody was Somebody after all :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jeremy Dunck]

On Wed, Oct 21, 2009 at 2:22 PM, mrts <mrts.pydev@...> wrote:
...
> Django Bug Days
> ---------------
>
> At regular intervals, say twice a month on Saturdays,
> set aside 2-3 hours for IRC-based bug hunting sprints.

If we do this, I think the time slot should rotate to allow different
timezones to participate; +6 hours each occurrence?

> Devs list tickets that they want people to work on and
> people are free to suggest their own.  Work is done over
> longer periods, but the bug days provide an occasion to
> get feedback from the devs.

I think, really, any ticket without "has patch" or with "patch needs
improvement" is that list.  Asking the core devs to pick bugs to focus
on is sort of defeating the purpose; we're trying to grease the
wheels, not give core more to do.

> The patches will perhaps not be integrated into SVN but to a
> branch on a DVCS (see the next suggestion).

git clone http://github.com/django/django/
git checkout -b bughunt-<ticket#> master
#patch, w/ docs and tests
#update code.djangoproject for ticket#, pointing to repo's commit?

Core, is this really an improvement over patches attached to tickets?

> Added benefit: if nobody shows up, they have no right to
> grumble on the mailing list :).

...Until someone feels frustrated that *this* isn't incorporated fast
enough.  :-/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@...
To unsubscribe from this group, send email to django-developers+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---