About the django-core mailing list
Jacob Kaplan-Moss
A bit of context before I dive in: at DjangoCon, Eric Florenzano gave
a "what's broken about Django" talk. I sadly had to miss DjangoCon,
and so I'm anxiously waiting to see the video, but I did see one thing
in the slides I thought I should address right away. Actually, this is
something we should have made clearer *long* ago, but better late than
never, I suppose.
So yes, there is a "django-core" mailing list, which is private and
by-invitiation-only. Only committers have access to this list and to
its archives. This smacks of insularism, and sounds exclusionary, and
in general is a pretty bad "symbol" to our community. If we're an open
community, and if we accept contributions from anyone, why the heck
does this list exist?
For a *long* time we tried to avoid having any such private list on
the theory that we should try to be as open as possible. I resisted
creating the list for as long as possible, and I'm still somewhat
unhappy that it's a necessity. Now that it's there, we try to use it
as little as possible
However, at a certain point we finally realized that we *did* need a
place to discuss issues too sensitive for public discourse. Those
things are:
1. Security-related issues. When we receive a security report, we need
to discuss it in private. As soon as an issue is made public we're
entered into a race against malicious script kiddies, so we need some
place to discuss and resolve security issues and then coordinate
issuing fixes outside of public scrutiny. This is, as far as I know,
considered to be a general best practice for open source projects. Our
security policy is detailed at
http://docs.djangoproject.com/en/1.2/internals/contributing/#reporting-security-issues,
and as always we're open to suggestions if folks think we're doing it
wrong.
2. Commit access. As everyone knows, we've got very high standards.
This means that when someone's nominated for commit access we want
have a frank, no-holds-barred discussion of that person's skills. This
discussion is a lot like the hire/no-hire discussion that an interview
team might have after talking to a candidate, which means that we
might say something about a candidate's ability that isn't so nice.
It's not fair to the candidate to have his or her merits and demerits
discussed publicly, and we feel we need to freedom that privacy brings
if we're going to be honest.
Those were the two reasons that led us to create the list. This list
is used infrequently -- there have been about 670 messages since it
was started in 2007 -- and the above two topics dominate the archives.
However, looking over the archives there *are* a few other types of
threads we've had:
3. Procedural complaints, screeds, or intra-personal problems.
Sometimes we need a venue to vent to other core developers. There've
been a few threads on this list of the years that, quite simply, would
have been taken completely out of context if posted publicly. We all
know each other very well, and so if I post a major rant on
django-core everyone else there knows me well enough to take it in
context, extract the constructive aspects, and ignore the rest. If
this rant was posted publically we'd have all sorts of "OMG Django
Lead Developer Disses Project!!!111eleven" posts on Reddit and such.
Good times.
If not for django-core these would be posted over private email or
simply left unsaid, so I'm okay with continuing to use a private list
for... well... private things!
4. Coordination -- release dates, timelines, etc. We've also used
django-core to discuss release schedules and other process
coordination.
In retrospect, I'm *not* comfortable with the use of django-core for
stuff like this. I suspect we've used the private list to prevent the
type of bikeshedding that usually happens when trivial things like
release dates and timelines come up, but that's a bad reason. I'm no
longer going to use a private list for this stuff, and I'm going to
encourage others to stop.
* * *
I hope this clears up why we (think we) require a private list, and I
hope it makes the activities on that list transparent enough. If
anyone has any questions or concerns -- now or any time -- about this
list or any other private communication among the core team, please
feel free to bring those concerns up -- here, or to me in private
email, or wherever.
The goal is to only be private when we absolutely *must*, and if we're
not sufficiently transparent *please* say something.
Jacob
Dennis Kaarsemaker
> The goal is to only be private when we absolutely *must*, and if we're
> not sufficiently transparent *please* say something.
Thanks Jacob, for explaining this.
This makes a good amount of sense, and Django is not unique here. I am
involved with other high-profile open source projects where similar
'core' lists exist for the very same reasons, except for the
coordination bits, which you already addressed as possibly being a bad
topic for a private list. It works very well for these projects and I am
convinced it works well for any project, if used responsibly.
--
Dennis K.
They've gone to plaid!
Simone Federici
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Anton Bessonov
But also +1 for other points in Eric's presentation.
Jerome Leclanche
mailing lists, such as -security, I'm very glad Jacob took the time to
explain the need for its presence in Django. And a big +1 on
scheduling releases in public.
J. Leclanche
Richard Laager
> 1. Security-related issues. When we receive a security report, we need
> to discuss it in private.
Just as a data point...
I'm a committer on a widely-used open source application, and we discuss
these things on a "packagers" list. As the name suggests, this list
includes the package maintainers for various distros. I think they find
this very useful and I know we find their input helpful.
Richard
Graham Dumpleton
On Sep 10, 8:41 am, Anton Bessonov <exe...@googlemail.com> wrote:
> +1. Explaining existence of private core-list is needless.
The Apache Software Foundation would be a good example of where a lot
of effort has been taken to explain how things work. The result is
that even though there are closed groups within that structure, people
at least know they exist, why they exist, why they are closed and what
they do. Most will not read this stuff, but for those who fuss over
such things, all the information is there.
http://www.apache.org/foundation/how-it-works.html#structure
As a possible analogue to this core developers list, in the ASF you
have various project management committees. These PMCs have closed
mailing lists for discussion, albeit mainly for administrative
matters. The scope of what these do is also described.
http://www.apache.org/dev/pmc.html
Graham
Anton Bessonov
> I disagree. Although it is normal for a project to have private
> mailing lists, such as -security
> I'm very glad Jacob took the time to
> explain the need for its presence in Django.
repo? Even for OpenSource there is one thousand reasons to have the
private list.
Jerome Leclanche
>
>> I disagree. Although it is normal for a project to have private
>> mailing lists, such as -security
>
> You disagree, but it is normal? Decide for you first.
I disagree that there was no explanation necessary. As Graham very
elegantly put it up, any information on why a structure exists is
good.
>>
>> I'm very glad Jacob took the time to
>> explain the need for its presence in Django.
>
> There is a difference about knowledge of the confidential list, trac, repo?
> Even for OpenSource there is one thousand reasons to have the private list.
I have no idea what you are getting at.
J. Leclanche
Anton Bessonov
> I would say that any information on why a structure exists is good.
>
There is no difference have developers a confidential list, a chat or
they communicate by phone, right? It has no relation to structure. It is
a natural way for the decision not public problems.