Regularly-scheduled Django sprints, first December 11 - 13

[Jeremy Dunck]

Djangonauts,
  To help speed along development on Django, I'd like us to start
holding regularly-scheduled sprints.  I've previously contacted core
committers to see who would be willing to supply the commit bits for
the sprint workflow.  I'm now looking for members of the dev list to
help organize locally.  If you would be willing to help organize your
local Django developers, the DSF can pay for lunches or similar costs.
 It doesn't take much effort-- you just need a place to work that
offers a good network connection and a little coordination to get
people together.  If you're an experienced contributor, great, but
there will be people on #django-dev and #django-sprint to help out,
too.  We can certainly get a committer available online.  In some
cases, we can get a committer on-site to help things along as well.

  To start, let's try running a sprint once every two months.  I don't
think the specific days matter too much, but for a start, let's say
the second Friday through Sunday of every second month, starting in
December.  That would make the first scheduled sprint December 11 -
13.  Since we have developers world-wide, I think it would make sense
to have the sprint roll across the time zones, starting at Fri 11 Dec
at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00
UTC [2].  Within that range of time, local groups can gather with some
assurance that a committer will be available at least virtually.

  It'd be lovely to get more than one location per sprint, and I'd
like to ensure that people all over at least have a reasonable chance
to attend a gathering.  The exact days and start times will be up to
local organizers-- I'm just trying to make some conventions so we
don't have to fiddle with configuration so much.

  If you're willing to organize a sprint gathering during this time
span, please let me know and I'll help to ensure committers are
available and to promote the sprint gathering.  (There's actually
pretty good guidance on the Sprints wiki page [3].)

  Even if you can't host on those dates, but would like to host in the
future, please let me know so I can have a list of candidates to work
from in the future.

[1]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196
[2]
http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196
[3]
http://code.djangoproject.com/wiki/Sprints

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

On Tue, Nov 10, 2009 at 11:00 AM, Jeremy Dunck <jdunck@...> wrote:

>
> Djangonauts,
>  To help speed along development on Django, I'd like us to start
> holding regularly-scheduled sprints.  I've previously contacted core
> committers to see who would be willing to supply the commit bits for
> the sprint workflow.  I'm now looking for members of the dev list to
> help organize locally.  If you would be willing to help organize your
> local Django developers, the DSF can pay for lunches or similar costs.
>  It doesn't take much effort-- you just need a place to work that
> offers a good network connection and a little coordination to get
> people together.  If you're an experienced contributor, great, but
> there will be people on #django-dev and #django-sprint to help out,
> too.  We can certainly get a committer available online.  In some
> cases, we can get a committer on-site to help things along as well.
>
>  To start, let's try running a sprint once every two months.  I don't
> think the specific days matter too much, but for a start, let's say
> the second Friday through Sunday of every second month, starting in
> December.  That would make the first scheduled sprint December 11 -
> 13.  Since we have developers world-wide, I think it would make sense
> to have the sprint roll across the time zones, starting at Fri 11 Dec
> at 18:00 UTC [1] and running continuously until Mon 14 Dec at 00:00
> UTC [2].  Within that range of time, local groups can gather with some
> assurance that a committer will be available at least virtually.
>
>  It'd be lovely to get more than one location per sprint, and I'd
> like to ensure that people all over at least have a reasonable chance
> to attend a gathering.  The exact days and start times will be up to
> local organizers-- I'm just trying to make some conventions so we
> don't have to fiddle with configuration so much.
>
>  If you're willing to organize a sprint gathering during this time
> span, please let me know and I'll help to ensure committers are
> available and to promote the sprint gathering.  (There's actually
> pretty good guidance on the Sprints wiki page [3].)
>
>  Even if you can't host on those dates, but would like to host in the
> future, please let me know so I can have a list of candidates to work
> from in the future.
>
> [1]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=11&hour=18&min=0&sec=0&p1=64&p2=37&p3=196
> [2]
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=12&day=14&hour=0&min=0&sec=0&p1=64&p2=37&p3=196
> [3]
> http://code.djangoproject.com/wiki/Sprints
>
> >
>

From December 19th through January 24th I will be willing to do
anything necessary to organize a sprint in Chicago, hopefully it won't
be too hard to drag our local core devs there :).  Let me know what
the sprint date would be over that time period and I can start working
things out.

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~---------~--~----~------------~-------~--~----~
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 Tue, Nov 10, 2009 at 10:04 AM, Alex Gaynor <alex.gaynor@...> wrote:
...
> From December 19th through January 24th I will be willing to do
> anything necessary to organize a sprint in Chicago, hopefully it won't
> be too hard to drag our local core devs there :).  Let me know what
> the sprint date would be over that time period and I can start working
> things out.

Ah, winter break.  :-)  2nd weekend is Jan 8-10, so let's say that?

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Sean Brant]

Alex, I can help you out in Chicago if you need it.

Sean

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Alex Gaynor]

On Tue, Nov 10, 2009 at 11:14 AM, Sean Brant <brant.sean@...> wrote:
>
> Alex, I can help you out in Chicago if you need it.
>
> Sean
>
> >
>

Sure that'd be great, I guess we don't really need to start planning
until it gets a little closer, but if we want to have any discussions
about the local things let's try to revive the django-chicago mailing
list :)

Alex

--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Sean Brant]

> Sure that'd be great, I guess we don't really need to start planning
> until it gets a little closer, but if we want to have any discussions
> about the local things let's try to revive the django-chicago mailing
> list :)
>
> Alex

Yeah, I agree. If you need admin access to that list I think Tom can
help with that.

Sean

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Eric Holscher]

I would be up for getting one together in Lawrence. Our offices at LJ World have always been a good place in the past, and I'm sure we can use them again.



--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.com

--~--~---------~--~----~------------~-------~--~----~
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]

I'd be willing to help organize one in the Triangle area of North
Carolina (Raleigh, Durham, Chapel Hill). We're just getting a Django
Users Group setup (TriDjUG) and there is already a thriving Python
Users Group (TriZPUG) in the area. I'm sure we could get a decent turn
out.

Thanks for kicking this off!

Paul

--~--~---------~--~----~------------~-------~--~----~
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]

Great news! Have you discussed the workflow yet?
I.e. will a DVCS be involved, and if yes, will there be
a central repo for coordinating the effort?

A special repo on Github would otherwise be perfect,
but as mentioned before, we have a problem with re-forking:
http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo

Whatever workflow and tools have been or will be
picked, may I suggest that clear instructions be written
for participants -- e.g. something in the lines of [1]?

[1] http://code.djangoproject.com/wiki/CollaborateOnGithub
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[JeffAmmons]

This is still a little ways out, but Mahalo.com will be hosting a sprint in the next round in February in Santa Monica, CA. We're still looking for core developers in the area, so if you know any or are one, let me know.

-Jeff

On Tue, Nov 10, 2009 at 9:06 AM, mrts <mrts.pydev@...> wrote:

Great news! Have you discussed the workflow yet?
I.e. will a DVCS be involved, and if yes, will there be
a central repo for coordinating the effort?

A special repo on Github would otherwise be perfect,
but as mentioned before, we have a problem with re-forking:
http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo

Whatever workflow and tools have been or will be
picked, may I suggest that clear instructions be written
for participants -- e.g. something in the lines of [1]?

[1] http://code.djangoproject.com/wiki/CollaborateOnGithub

--~--~---------~--~----~------------~-------~--~----~
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 Wed, Nov 11, 2009 at 1:06 AM, mrts <mrts.pydev@...> wrote:
>
> Great news! Have you discussed the workflow yet?
> I.e. will a DVCS be involved, and if yes, will there be
> a central repo for coordinating the effort?
>
> A special repo on Github would otherwise be perfect,
> but as mentioned before, we have a problem with re-forking:
> http://support.github.com/discussions/feature-requests/560-two-forks-of-a-single-repo

Why do we need a central repository to coordinate a sprint effort? The
whole *point* using a DVCS is that you *don't* need a central
repository to coordinate activity.

Also - I know you're very enthused about Git and GitHub, but Django
uses SVN as the canonical store for trunk and branches, and this isn't
likely to change in the near future.

That said, many of the core developers use DVCS tools to manage their
day-to-day Django contributions. If you comment on a ticket that your
patch is also available as a pull from <insert repo here>, some core
developers will be able to exploit this.

As I have said to you in the past - if you want to make your
contribution to Django to be a DVCS  repository that acts as a staging
area for trunk-ready patches, that would be a very helpful
contribution. This is doubly true during a sprint - sprints generate a
lot of activity, so having good lieutenants to triage contributions is
extremely useful.

The important part is *not* the documentation of this process. The
important part is *doing the work*.

> Whatever workflow and tools have been or will be
> picked, may I suggest that clear instructions be written
> for participants -- e.g. something in the lines of [1]?

Django's workflow *is* documented:

http://docs.djangoproject.com/en/dev/internals/contributing/

The wiki page on Sprints clarify this process for sprints:

http://code.djangoproject.com/wiki/Sprints#Howtocontribute

Quoting:
"""
How to contribute

It's easy: Pick something to work on and do it.
"""

Key phrase: Do it. Not write an essay about how you would do it, and
then enter into a debate about whether the workflow that you have
proposed is optimal. Do the work, then tell a core dev that you have
done the work. Fix the patch if required. Rinse. Repeat.

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
-~----------~----~----~----~------~----~------~--~---

[Russell Keith-Magee-2]

On Wed, Nov 11, 2009 at 12:00 AM, Jeremy Dunck <jdunck@...> wrote:
>
> Djangonauts,
>  To help speed along development on Django, I'd like us to start
> holding regularly-scheduled sprints.

On behalf of the core team, I'd like to thank Jeremy for taking the
lead on this. Organizing an event like a sprint isn't glamourous work,
but it really helps the community, and it's an area where the core
team has been letting the community down. Thanks, Jeremy!

>  If you're willing to organize a sprint gathering during this time
> span, please let me know and I'll help to ensure committers are
> available and to promote the sprint gathering.  (There's actually
> pretty good guidance on the Sprints wiki page [3].)

If there is any interest in an IRL sprint based in Perth, Western
Australia, or Brisbane, Queensland, let me know - I may be able to
call in some favors and organize a venue. Failing that, I'll be
floating around the tubes on the day (and evening).

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
-~----------~----~----~----~------~----~------~--~---

[mrts-2]

On Nov 11, 1:57 pm, Russell Keith-Magee <freakboy3...@...>
wrote:
> Also - I know you're very enthused about Git and GitHub, but Django
> uses SVN as the canonical store for trunk and branches, and this isn't
> likely to change in the near future.

Thank you, but no, I'm not enthused about git and GitHub per
se :) -- I'm enthused that it's possible to maintain patches
and collaborate remotely with less agony by utilizing them.

Please let's be friendly and relaxed -- I was just asking
how do people plan to manage things. SVN is fine as well,
but it puts the burden of integrating work on core. It's
not the tool, but the goal that matters.

As far as I understand, that's one of the issues we are trying
to solve -- integrating contributors' work faster than core
is able to. Good for core and good for the contributors.

> As I have said to you in the past - if you want to make your
> contribution to Django to be a DVCS  repository that acts as a staging
> area for trunk-ready patches, that would be a very helpful
> contribution. This is doubly true during a sprint - sprints generate a
> lot of activity, so having good lieutenants to triage contributions is
> extremely useful.

Done, http://github.com/django-mq/django-mq .

I'm willing to regularly review pull requests and add
collaborators who are willing to do the same.

But there's the problem that I'm not Andy Morton --
considering my karma, I'm in no position in regard
to my "social capital" to lieutenant this.

> The important part is *not* the documentation of this process. The
> important part is *doing the work*.
>
> Key phrase: Do it. Not write an essay about how you would do it, and
> then enter into a debate about whether the workflow that you have
> proposed is optimal. Do the work, then tell a core dev that you have
> done the work. Fix the patch if required. Rinse. Repeat.

Wasn't the fact that it isn't and can't be that easy the
main problem we discussed in the angst-thread? That core is
too overburdened and small in numbers to oversee >1800 open
tickets?

Doing the work is usually easy, integration and avoiding
staleness is not.

As for "don't write essays" -- some traction is needed
behind the initiative and good coordination with core so
that the contributions start eventually flowing from the
repo back to the trunk. Few or no people will use the repo
unless there's a general consensus that it's a good thing.
That consensus can only come from clear understanding of
it's purpose and workflow (the "essays") -- only then can
people start contributing. Otherwise they will feel that
it's a waste of their time on an obscure fringe thing.

All in all, I think that we are not really on different positions
regarding this, it's just the karma issue that spoils the soup :)
So be it, I'll just try to keep my mouth shut.

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
-~----------~----~----~----~------~----~------~--~---

[Jacob Kaplan-Moss-2]

On Wed, Nov 11, 2009 at 3:57 PM, mrts <mrts.pydev@...> wrote:
> Done, http://github.com/django-mq/django-mq .
>
> I'm willing to regularly review pull requests and add
> collaborators who are willing to do the same.

I'll keep an eye on your queue; I can easily push good patches from
there upstream to SVN.

If you stick patches into separate branches -- I suggest naming 'em
something like "trac/1234-short-ticket-desc" (where 1234 is the ticket
number) -- that'll make it easy for us Githeads to merge in ticket
fixes you post there.

Please, though, stress to people who want to use your queue that they
should *also* post patches to Trac. It's easier to review that way,
and it's more friendly to those not using Git.

Thanks

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 Thu, Nov 12, 2009 at 5:57 AM, mrts <mrts.pydev@...> wrote:

>
> On Nov 11, 1:57 pm, Russell Keith-Magee <freakboy3...@...>
> wrote:
>> Also - I know you're very enthused about Git and GitHub, but Django
>> uses SVN as the canonical store for trunk and branches, and this isn't
>> likely to change in the near future.
>
> Thank you, but no, I'm not enthused about git and GitHub per
> se :) -- I'm enthused that it's possible to maintain patches
> and collaborate remotely with less agony by utilizing them.
>
> Please let's be friendly and relaxed -- I was just asking
> how do people plan to manage things. SVN is fine as well,
> but it puts the burden of integrating work on core. It's
> not the tool, but the goal that matters.

SVN is a sucky tool, but it really isn't the bottleneck in the
process. The bottleneck is deciding which one of a thousand patches I
(or any other member of core) should merge into trunk next.

Git (or any other DVCS for that matter) doesn't solve that problem. No
tool will - it's a social problem, and there's no such thing as a
technical solution to a social problem.

>> As I have said to you in the past - if you want to make your
>> contribution to Django to be a DVCS  repository that acts as a staging
>> area for trunk-ready patches, that would be a very helpful
>> contribution. This is doubly true during a sprint - sprints generate a
>> lot of activity, so having good lieutenants to triage contributions is
>> extremely useful.
>
> Done, http://github.com/django-mq/django-mq .

Awesome. I look forward to seeing your work.

> I'm willing to regularly review pull requests and add
> collaborators who are willing to do the same.

Thats fine, but keep in mind that the value of this branch goes down
if the patches that are added to the branch aren't good. The risk of
adding lots of contributors is that you end up with a branch that is
just every ticket in Trac applied to trunk.

What we need is a genuine lieutenant - someone who exercises personal
taste and rejects patches when appropriate. A good lieutenant should
also give feedback to the original developer. What we don't need is
someone who just applies every patch they can. Applying a patch to a
tree is easy. Working out whether a patch is a good contribution is
hard.

> But there's the problem that I'm not Andy Morton --
> considering my karma, I'm in no position in regard
> to my "social capital" to lieutenant this.

But neither was Andy Morton when he started. That's the point. You
don't do this sort of thing *because* you have the karma - you do it
to *gain* the sort of karma that Andy Morton has. Through a lot of
hard work, Andy built a reputation as being someone with good design
taste that Linus can rely on as a rich vein of probably-trunk-ready
patches, and as a result, he is now a trusted lieutenant.

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
-~----------~----~----~----~------~----~------~--~---