subject:"Process discussion\: reboot"

On Wed, Apr 21, 2010 at 10:18 AM, SmileyChris  wrote:
> ... And it seems like i'm reiterating the discussion about
> http://code.djangoproject.com/wiki/TicketChangeHelp
>
> I'm advocating for the friendly text in the ticket page itself, as I'm
> not sure that was specifically mentioned in the related part of this
> thread (but probably implied)

Great idea :)

James' stats views are a pre-cursor to my 2nd idea from above -
sending "reminder" emails to people so tickets don't languish as much,
with suggestions on what to do and how to get help... would need to be
targeted carefully so people don't get spammed, but I think it could
be helpful. Getting a "hasn't made the freeze, bumping to future
release" comment when you could have found a couple of hours to finish
docs & tests is a bummer...

Rob :)

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

Re: Process discussion: reboot

2010-04-20 Thread Paul Egges

This sounds like a great idea to me.

+1 for me.  I've a been a bit reluctant to up my participation for a variety
of reasons, but kind of knowing how best to proceed is one of the large
ones.

Thanks,

Paul

On Tue, Apr 20, 2010 at 10:43 AM, Stephen Crosby wrote:

> What could be very helpful here is some education for would-be Django
> developers. The tutorial format has worked so well for educating new Django
> users, why not apply it also to Django developers also? After the 1.2
> release, why don't we come up with a Django developers tutorial that walks
> us through the process of solving issues and working on Django. The goal of
> this would be to help would-be developers understand the Django development
> process by getting their hands dirty with a real issue.
>
> It could begin with a short explanation of the process, go through finding
> a real (old) example issue in Trac (already solved), it could run down what
> type of Trac activity is helpful and what is not. Then the tutorial could
> instruct the reader to checkout an old revision of Django (with the unsolved
> issue) and how to reproduce the issue.
>
> We could show the reader how to apply a bad patch (attached by some
> less-informed Trac user), then how to run the test suite and notice that
> some tests fail. Some instruction on how to politely note that fact on Trac
> might be in order as well as how the patch was rewritten in order to pass
> the tests.
>
> Another bit on proper documentation, some notes on quality, where to get
> help, what types of issues need discussion on this list would be great and
> I'm sure there's more that could be included with this type of tutorial.
>
>
> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss wrote:
>
>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
>> > When I finally did submit my first patch, I was terrified of getting
>> > it wrong and having it rejected. I'd seen it happen on other tickets.
>> > It wasn't until I got *more involved* and started keeping up with the
>> > trac timeline--watching the ebb and flow of tickets--that I started to
>> > understand how the tone on trac had a reason. Until you get that
>> > perspective, it's hard to know what's right or wrong, and easy to take
>> > things personally. The core devs can seem imposing or scary simply
>> > because you don't know them.
>>
>> This is *really* good feedback, and thank you very much for it.
>>
>> Clearly scaring people isn't our intent, but if that's the result...
>> well, we're doing something wrong. I really don't want people to be
>> scared off, and I'm hearing from you and a few others that that's
>> already happening.
>>
>> I don't think I need to enumerate why the tone on a ticket tracker
>> tends towards the terse -- lack of time, repetition, yadayada -- but
>> regardless I don't like our process being scary.
>>
>> > If anything, my point is that getting started as a Django contributor
>> > *can* be difficult, and the core team just being aware of that fact is
>> > a good thing.
>>
>> I hear you loud and clear, and I'd love any suggestions you might have
>> about how we might improve in this area.
>>
>> Jacob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
>
> --
> Stephen Crosby
> Web Developer
> lithostech.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: Process discussion: reboot

2010-04-20 Thread SmileyChris

... And it seems like i'm reiterating the discussion about
http://code.djangoproject.com/wiki/TicketChangeHelp

I'm advocating for the friendly text in the ticket page itself, as I'm
not sure that was specifically mentioned in the related part of this
thread (but probably implied)

On Apr 21, 10:13 am, SmileyChris  wrote:

> In a similar vein, it'd also be great if under the ticket summary,
> some "hooks" based on the current ticket state could be added.

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

Re: Process discussion: reboot

On Wed, Apr 21, 2010 at 10:00 AM, Jacob Kaplan-Moss  wrote:
> On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup
>  wrote:
>
>> I can write you a trac extension/patch - just didn't want to spend the
>> time on it if nobody was keen. May be as simple as customising the
>> email template, but we don't want it to send out stuff whenever
>> someone is added to the CC list, etc.
>
> If you wrote such a extension, I'll get it onto our Trac. I'm wary of
> a patch, though, so if it's not possible without one we could just
> include a link to this page in a bunch of prominent places including
> the email itself.

I'll have a dig around in Trac over the next couple of days and see
what its going to take.

Rob :)

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

Re: Process discussion: reboot

2010-04-20 Thread SmileyChris

On Apr 21, 9:46 am, Jeremy Dunck  wrote:
> [...]  Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of time -- a summary of min, max, mean time in queue (over time), and
> a detail view to sort tickets by age in queue, etc.

I agree that the perception definitely discourages contribution.

Reports which could identify "stale" tickets would be neat.

In a similar vein, it'd also be great if under the ticket summary,
some "hooks" based on the current ticket state could be added. E.g.:
"This ticket requires documentation - can you assist by adding some?",
or "Please try out the latest patch and report back as to whether it's
working for you".

While these next actions are obviously implied, explicitly suggesting
them encourages contribution.

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

Re: Process discussion: reboot

2010-04-20 Thread Gabriel Hurley

I just built something in a similar vein as this for my team's
internal use. Amusingly, I used Django's inspectdb feature to directly
interface with Redmine's database and provide a separate front-end.
The data feeds into a javascript graphing library.

The ability to visualize languishing issues, activity over time, etc.
is really pretty awesome. I've got no experience hacking at Trac
particularly, but I can at least speak to how useful having that kind
of resource can be.

- Gabriel

On Apr 20, 2:46 pm, Jeremy Dunck  wrote:
> On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss  wrote:
>
> ...
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> I have a perception that there are some phases of the ticket lifecycle
> where things get stuck -- I think that if you look at this 
> diagram:http://docs.djangoproject.com/en/dev/_images/djangotickets.png
> there is a pretty clear flow, and people are encouraged to pitch in
> where ever they feel it might help.
>
> But in practice, it seems that some of the edges become queues, and
> some tickets sit in that queue for a long time -- either because the
> next step for that ticket isn't obvious, or because there's a shortage
> of triage attention on that particular ticket.
>
> Earlier in the other thread, someone claimed there were hundreds of
> patches ready (but ignored), while the response was "no, those tickets
> aren't actually ready" -- the issue was a recognition of procedure, in
> that case.  Even so, the perception of ignored tickets is part of the
> problem-- whether tickets are actually ignored or not, the perception
> still would discourage contribution.
>
> I'd like to highlight tickets that have sat in each queue for a period
> of time -- a summary of min, max, mean time in queue (over time), and
> a detail view to sort tickets by age in queue, etc.
>
> I know this isn't well-supported by Trac, but Joseph pointed me at the
> XML RPC API--- the pieces are there.  I never worked on it; generally,
> I felt that the triagers are doing what they can and if anything, my
> time would be better spent fixing bugs or triaging.
>
> But this debate has been at least partially about responsiveness and
> the perception of inclusion.
>
> Triagers, commiters, off-put contributors, do you think this sort of
> view would help the workflow and understanding of the ticket status?
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

2010-04-20 Thread Gabriel Hurley

That sounds like a great idea! Even having been at this for a few
months I'd watch it just to see how somebody else handles things.

On Apr 20, 10:55 am, Alex Gaynor  wrote:
> On Tue, Apr 20, 2010 at 1:36 PM, Bmheight  wrote:
> > +1 to Stephen Crosbys' proposal, although I think this would be a bit
> > difficult to perform as the Framework evolves and the documentation on this
> > would be a bit outdated as time goes on (And have to yet again maintain
> > another Document to keep up to date).
> > It it still none the less a good idea in my opinion.
>
> > On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby 
> > wrote:
>
> >> What could be very helpful here is some education for would-be Django
> >> developers. The tutorial format has worked so well for educating new Django
> >> users, why not apply it also to Django developers also? After the 1.2
> >> release, why don't we come up with a Django developers tutorial that walks
> >> us through the process of solving issues and working on Django. The goal of
> >> this would be to help would-be developers understand the Django development
> >> process by getting their hands dirty with a real issue.
> >> It could begin with a short explanation of the process, go through finding
> >> a real (old) example issue in Trac (already solved), it could run down what
> >> type of Trac activity is helpful and what is not. Then the tutorial could
> >> instruct the reader to checkout an old revision of Django (with the 
> >> unsolved
> >> issue) and how to reproduce the issue.
> >> We could show the reader how to apply a bad patch (attached by some
> >> less-informed Trac user), then how to run the test suite and notice that
> >> some tests fail. Some instruction on how to politely note that fact on Trac
> >> might be in order as well as how the patch was rewritten in order to pass
> >> the tests.
> >> Another bit on proper documentation, some notes on quality, where to get
> >> help, what types of issues need discussion on this list would be great and
> >> I'm sure there's more that could be included with this type of tutorial.
>
> >> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss 
> >> wrote:
>
> >>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
> >>> > When I finally did submit my first patch, I was terrified of getting
> >>> > it wrong and having it rejected. I'd seen it happen on other tickets.
> >>> > It wasn't until I got *more involved* and started keeping up with the
> >>> > trac timeline--watching the ebb and flow of tickets--that I started to
> >>> > understand how the tone on trac had a reason. Until you get that
> >>> > perspective, it's hard to know what's right or wrong, and easy to take
> >>> > things personally. The core devs can seem imposing or scary simply
> >>> > because you don't know them.
>
> >>> This is *really* good feedback, and thank you very much for it.
>
> >>> Clearly scaring people isn't our intent, but if that's the result...
> >>> well, we're doing something wrong. I really don't want people to be
> >>> scared off, and I'm hearing from you and a few others that that's
> >>> already happening.
>
> >>> I don't think I need to enumerate why the tone on a ticket tracker
> >>> tends towards the terse -- lack of time, repetition, yadayada -- but
> >>> regardless I don't like our process being scary.
>
> >>> > If anything, my point is that getting started as a Django contributor
> >>> > *can* be difficult, and the core team just being aware of that fact is
> >>> > a good thing.
>
> >>> I hear you loud and clear, and I'd love any suggestions you might have
> >>> about how we might improve in this area.
>
> >>> Jacob
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "Django developers" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected].
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/django-developers?hl=en.
>
> >> --
> >> Stephen Crosby
> >> Web Developer
> >> lithostech.com
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Django developers" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group at
> >>http://groups.google.com/group/django-developers?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> FWIW I've long been considering doing a screencast on how t

Re: Process discussion: reboot

2010-04-20 Thread Gabriel Hurley

That's awesome. I'll definitely add to that when I have some time
tonight.

On Apr 20, 2:49 pm, Robert Coup 
wrote:
> On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss  wrote:
> > I like this a lot. Especially the "your next steps" part - it makes it
> > very obvious what the next thing interested parties should do is.
>
> > Could you start a wiki page with this stuff? Until we figure out how
> > to get it more visible, it could at least serve as a sort of FAQ about
> > what different ticket actions mean. Starting it on the wiki means
> > folks can pitch in and help get the wording good.
>
> Tada...http://code.djangoproject.com/wiki/TicketChangeHelp
>
> Most of it is empty - please help fill it in!
>
>
>
> > In the meantime, I'll look into how to get it into Trac somehow.
>
> I can write you a trac extension/patch - just didn't want to spend the
> time on it if nobody was keen. May be as simple as customising the
> email template, but we don't want it to send out stuff whenever
> someone is added to the CC list, etc.
>
> Rob :)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup
 wrote:
> Tada... http://code.djangoproject.com/wiki/TicketChangeHelp
>
> Most of it is empty - please help fill it in!

This is an awesome start - thanks! I'll try to help fill stuff in and
edit for tone/style as I can.

> I can write you a trac extension/patch - just didn't want to spend the
> time on it if nobody was keen. May be as simple as customising the
> email template, but we don't want it to send out stuff whenever
> someone is added to the CC list, etc.

If you wrote such a extension, I'll get it onto our Trac. I'm wary of
a patch, though, so if it's not possible without one we could just
include a link to this page in a bunch of prominent places including
the email itself.

Jacob

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

Re: Process discussion: reboot

On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss  wrote:
> I like this a lot. Especially the "your next steps" part - it makes it
> very obvious what the next thing interested parties should do is.
>
> Could you start a wiki page with this stuff? Until we figure out how
> to get it more visible, it could at least serve as a sort of FAQ about
> what different ticket actions mean. Starting it on the wiki means
> folks can pitch in and help get the wording good.

Tada... http://code.djangoproject.com/wiki/TicketChangeHelp

Most of it is empty - please help fill it in!

>
> In the meantime, I'll look into how to get it into Trac somehow.

I can write you a trac extension/patch - just didn't want to spend the
time on it if nobody was keen. May be as simple as customising the
email template, but we don't want it to send out stuff whenever
someone is added to the CC list, etc.

Rob :)

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

Re: Process discussion: reboot

2010-04-20 Thread Jeremy Dunck

On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss  wrote:
...
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.

I have a perception that there are some phases of the ticket lifecycle
where things get stuck -- I think that if you look at this diagram:
http://docs.djangoproject.com/en/dev/_images/djangotickets.png
there is a pretty clear flow, and people are encouraged to pitch in
where ever they feel it might help.

But in practice, it seems that some of the edges become queues, and
some tickets sit in that queue for a long time -- either because the
next step for that ticket isn't obvious, or because there's a shortage
of triage attention on that particular ticket.

Earlier in the other thread, someone claimed there were hundreds of
patches ready (but ignored), while the response was "no, those tickets
aren't actually ready" -- the issue was a recognition of procedure, in
that case.  Even so, the perception of ignored tickets is part of the
problem-- whether tickets are actually ignored or not, the perception
still would discourage contribution.

I'd like to highlight tickets that have sat in each queue for a period
of time -- a summary of min, max, mean time in queue (over time), and
a detail view to sort tickets by age in queue, etc.

I know this isn't well-supported by Trac, but Joseph pointed me at the
XML RPC API--- the pieces are there.  I never worked on it; generally,
I felt that the triagers are doing what they can and if anything, my
time would be better spent fixing bugs or triaging.

But this debate has been at least partially about responsiveness and
the perception of inclusion.

Triagers, commiters, off-put contributors, do you think this sort of
view would help the workflow and understanding of the ticket status?

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

Re: Process discussion: reboot

2010-04-20 Thread Brandon H



+1

I would also be willing to contribute some time in developing this Wiki 
page, editing, etc.




On Tue, 20 Apr 2010, Jacob Kaplan-Moss wrote:


On Tue, Apr 20, 2010 at 3:53 PM, Robert Coup
 wrote:

Idea #1:
When a ticket is currently closed Trac sends you an email saying
"status:closed resolution:wontfix" and whatever comment is made by the
person who closed it.
How about a plugin for Trac that expands these ... "concise" emails with
some docs and links, so reporters can (a) get a better explanation of why
something has been changed, and (b) have a clear direction going forward.
Just putting the comments in the email above the "resolution:wontfix" I
think would provide a better (less emotional, more rational) experience for
a reader.
eg. Closed-as-Duplicate:
"
By closing duplicate tickets, we keep all the discussion about a topic in
one place, which helps everyone.
Your next steps:
1. Check out the linked ticket that is referred to above.
2. Add any relevant notes/patches/discussion from here to the other ticket.
3. If you don't agree that it's a duplicate, please reopen the ticket and
explain why (mistakes do happen!).
"
likewise for the other resolutions, and also setting of custom fields (eg.
needs_better_patch, needs_tests, needs_documentation).


I like this a lot. Especially the "your next steps" part - it makes it
very obvious what the next thing interested parties should do is.

Could you start a wiki page with this stuff? Until we figure out how
to get it more visible, it could at least serve as a sort of FAQ about
what different ticket actions mean. Starting it on the wiki means
folks can pitch in and help get the wording good.

In the meantime, I'll look into how to get it into Trac somehow.

Jacob

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




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

Re: Process discussion: reboot

On Tue, Apr 20, 2010 at 3:53 PM, Robert Coup
 wrote:
> Idea #1:
> When a ticket is currently closed Trac sends you an email saying
> "status:closed resolution:wontfix" and whatever comment is made by the
> person who closed it.
> How about a plugin for Trac that expands these ... "concise" emails with
> some docs and links, so reporters can (a) get a better explanation of why
> something has been changed, and (b) have a clear direction going forward.
> Just putting the comments in the email above the "resolution:wontfix" I
> think would provide a better (less emotional, more rational) experience for
> a reader.
> eg. Closed-as-Duplicate:
> "
> By closing duplicate tickets, we keep all the discussion about a topic in
> one place, which helps everyone.
> Your next steps:
> 1. Check out the linked ticket that is referred to above.
> 2. Add any relevant notes/patches/discussion from here to the other ticket.
> 3. If you don't agree that it's a duplicate, please reopen the ticket and
> explain why (mistakes do happen!).
> "
> likewise for the other resolutions, and also setting of custom fields (eg.
> needs_better_patch, needs_tests, needs_documentation).

I like this a lot. Especially the "your next steps" part - it makes it
very obvious what the next thing interested parties should do is.

Could you start a wiki page with this stuff? Until we figure out how
to get it more visible, it could at least serve as a sort of FAQ about
what different ticket actions mean. Starting it on the wiki means
folks can pitch in and help get the wording good.

In the meantime, I'll look into how to get it into Trac somehow.

Jacob

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

Re: Process discussion: reboot

Hi all,

On Tue, Apr 20, 2010 at 8:34 AM, Gabriel Hurley  wrote:

> When I finally did submit my first patch, I was terrified of getting
> it wrong and having it rejected. I'd seen it happen on other tickets.
>

As a project, I'm sure we don't want any (even potential) contributors to be
terrified. How can we fix that, and encourage people to work with the
process rather than deciding that Django is an elitist club and walking
away?

I've listed a couple of ideas below for enhancements to Trac to help a bit.
What do people think? Worth spending time on?

Rob :)

Idea #1:

When a ticket is currently closed Trac sends you an email saying
"status:closed resolution:wontfix" and whatever comment is made by the
person who closed it.

How about a plugin for Trac that expands these ... "concise" emails with
some docs and links, so reporters can (a) get a better explanation of why
something has been changed, and (b) have a clear direction going forward.
Just putting the comments in the email above the "resolution:wontfix" I
think would provide a better (less emotional, more rational) experience for
a reader.

eg. Closed-as-Duplicate:
"
By closing duplicate tickets, we keep all the discussion about a topic in
one place, which helps everyone.

Your next steps:
1. Check out the linked ticket that is referred to above.
2. Add any relevant notes/patches/discussion from here to the other ticket.
3. If you don't agree that it's a duplicate, please reopen the ticket and
explain why (mistakes do happen!).
"
likewise for the other resolutions, and also setting of custom fields (eg.
needs_better_patch, needs_tests, needs_documentation).

Idea #2:

Have a tool that goes through open tickets and finds ones where the ticket
is waiting on something (eg. docs) and nothing has happened for a while. It
could email the owner and remind them that (a) Django does care, and (b)
offer them some help:
 - suggest they add it to a "please i would love some help with
(documentation)(tests)" page, along the lines of the "Little, easy
improvements" page.
 - if its DDN, suggest they bring it up on django-developers
 - if they don't have time to work further on it, set the owner to nobody so
it doesn't look like someone is "working" on it

We could also run this a few weeks before feature-freeze so people can have
a chance to add docs/tests to tickets, upgrade them to be trunk-ready, and
not miss the bus for another release.

And (has been suggested before?) try and automatically apply the latest
patch on a ticket to trunk and add a comment if it stops applying cleanly.

Rob :)

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

Re: Process discussion: reboot

2010-04-20 Thread Gregor Müllegger

Also a +1 from me on the proposal for a tutorial for contributing and
how to get into the process of using Django's trac. I also tried to
get into triaging tickets a few times but I was very unsure in most
cases how to handle the status of the tickets, how to decide what
needs to be done or if this what I wanted to do is more a competence
of a core developer.

Gregor

On 20 Apr., 19:36, Bmheight  wrote:
> +1 to Stephen Crosbys' proposal, although I think this would be a bit
> difficult to perform as the Framework evolves and the documentation on this
> would be a bit outdated as time goes on (And have to yet again maintain
> another Document to keep up to date).
>
> It it still none the less a good idea in my opinion.
>
> On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby wrote:
>
>
>
> > What could be very helpful here is some education for would-be Django
> > developers. The tutorial format has worked so well for educating new Django
> > users, why not apply it also to Django developers also? After the 1.2
> > release, why don't we come up with a Django developers tutorial that walks
> > us through the process of solving issues and working on Django. The goal of
> > this would be to help would-be developers understand the Django development
> > process by getting their hands dirty with a real issue.
>
> > It could begin with a short explanation of the process, go through finding
> > a real (old) example issue in Trac (already solved), it could run down what
> > type of Trac activity is helpful and what is not. Then the tutorial could
> > instruct the reader to checkout an old revision of Django (with the unsolved
> > issue) and how to reproduce the issue.
>
> > We could show the reader how to apply a bad patch (attached by some
> > less-informed Trac user), then how to run the test suite and notice that
> > some tests fail. Some instruction on how to politely note that fact on Trac
> > might be in order as well as how the patch was rewritten in order to pass
> > the tests.
>
> > Another bit on proper documentation, some notes on quality, where to get
> > help, what types of issues need discussion on this list would be great and
> > I'm sure there's more that could be included with this type of tutorial.
>
> > On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss 
> > wrote:
>
> >> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
> >> > When I finally did submit my first patch, I was terrified of getting
> >> > it wrong and having it rejected. I'd seen it happen on other tickets.
> >> > It wasn't until I got *more involved* and started keeping up with the
> >> > trac timeline--watching the ebb and flow of tickets--that I started to
> >> > understand how the tone on trac had a reason. Until you get that
> >> > perspective, it's hard to know what's right or wrong, and easy to take
> >> > things personally. The core devs can seem imposing or scary simply
> >> > because you don't know them.
>
> >> This is *really* good feedback, and thank you very much for it.
>
> >> Clearly scaring people isn't our intent, but if that's the result...
> >> well, we're doing something wrong. I really don't want people to be
> >> scared off, and I'm hearing from you and a few others that that's
> >> already happening.
>
> >> I don't think I need to enumerate why the tone on a ticket tracker
> >> tends towards the terse -- lack of time, repetition, yadayada -- but
> >> regardless I don't like our process being scary.
>
> >> > If anything, my point is that getting started as a Django contributor
> >> > *can* be difficult, and the core team just being aware of that fact is
> >> > a good thing.
>
> >> I hear you loud and clear, and I'd love any suggestions you might have
> >> about how we might improve in this area.
>
> >> Jacob
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Django developers" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/django-developers?hl=en.
>
> > --
> > Stephen Crosby
> > Web Developer
> > lithostech.com
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.go

Re: Process discussion: reboot

2010-04-20 Thread Luke Plant

On Tuesday 20 April 2010 16:43:25 Alex Gaynor wrote:

> In general I don't think that the fields on tickets are nearly as
> liable to being inaccurate as people are making it sound.  That
> said marking users who are committers or triagers or what not
> probably wouldn't hurt.

Since our contributing rules say that you shouldn't re-open a ticket 
closed by a core dev, and it can be hard to find out who they are and 
what their Trac logins are, it is actually quite important that we 
have an easier way of finding out this information, especially for new 
contributors.

It's possible this Trac plugin could help (I haven't tested it):

  http://trac-hacks.org/wiki/UserManagerPlugin

We would need a wiki page (preferably linked from each ticket page) 
that included something like:

  = Core developers =

  [[UserProfilesList(role=developer)]] 

  = Triagers =

  [[UserProfilesList(role=triager)]] 

Luke

-- 
"I married Miss Right, I just didn't know her first name was 
'Always'"

Luke Plant || http://lukeplant.me.uk/

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

Re: Process discussion: reboot

2010-04-20 Thread Alex Gaynor

On Tue, Apr 20, 2010 at 1:36 PM, Bmheight  wrote:
> +1 to Stephen Crosbys' proposal, although I think this would be a bit
> difficult to perform as the Framework evolves and the documentation on this
> would be a bit outdated as time goes on (And have to yet again maintain
> another Document to keep up to date).
> It it still none the less a good idea in my opinion.
>
> On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby 
> wrote:
>>
>> What could be very helpful here is some education for would-be Django
>> developers. The tutorial format has worked so well for educating new Django
>> users, why not apply it also to Django developers also? After the 1.2
>> release, why don't we come up with a Django developers tutorial that walks
>> us through the process of solving issues and working on Django. The goal of
>> this would be to help would-be developers understand the Django development
>> process by getting their hands dirty with a real issue.
>> It could begin with a short explanation of the process, go through finding
>> a real (old) example issue in Trac (already solved), it could run down what
>> type of Trac activity is helpful and what is not. Then the tutorial could
>> instruct the reader to checkout an old revision of Django (with the unsolved
>> issue) and how to reproduce the issue.
>> We could show the reader how to apply a bad patch (attached by some
>> less-informed Trac user), then how to run the test suite and notice that
>> some tests fail. Some instruction on how to politely note that fact on Trac
>> might be in order as well as how the patch was rewritten in order to pass
>> the tests.
>> Another bit on proper documentation, some notes on quality, where to get
>> help, what types of issues need discussion on this list would be great and
>> I'm sure there's more that could be included with this type of tutorial.
>>
>> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss 
>> wrote:
>>>
>>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
>>> > When I finally did submit my first patch, I was terrified of getting
>>> > it wrong and having it rejected. I'd seen it happen on other tickets.
>>> > It wasn't until I got *more involved* and started keeping up with the
>>> > trac timeline--watching the ebb and flow of tickets--that I started to
>>> > understand how the tone on trac had a reason. Until you get that
>>> > perspective, it's hard to know what's right or wrong, and easy to take
>>> > things personally. The core devs can seem imposing or scary simply
>>> > because you don't know them.
>>>
>>> This is *really* good feedback, and thank you very much for it.
>>>
>>> Clearly scaring people isn't our intent, but if that's the result...
>>> well, we're doing something wrong. I really don't want people to be
>>> scared off, and I'm hearing from you and a few others that that's
>>> already happening.
>>>
>>> I don't think I need to enumerate why the tone on a ticket tracker
>>> tends towards the terse -- lack of time, repetition, yadayada -- but
>>> regardless I don't like our process being scary.
>>>
>>> > If anything, my point is that getting started as a Django contributor
>>> > *can* be difficult, and the core team just being aware of that fact is
>>> > a good thing.
>>>
>>> I hear you loud and clear, and I'd love any suggestions you might have
>>> about how we might improve in this area.
>>>
>>> Jacob
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django developers" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to
>>> [email protected].
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-developers?hl=en.
>>>
>>
>>
>>
>> --
>> Stephen Crosby
>> Web Developer
>> lithostech.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

FWIW I've long been considering doing a screencast on how to
contribute, picking a bug, diagnosing it, writing a patch, uploading
to trac, etc.  I'll take this as a sign that such a resource would be
helpful.

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
"C

Re: Process discussion: reboot

2010-04-20 Thread Bmheight

+1 to Stephen Crosbys' proposal, although I think this would be a bit
difficult to perform as the Framework evolves and the documentation on this
would be a bit outdated as time goes on (And have to yet again maintain
another Document to keep up to date).

It it still none the less a good idea in my opinion.

On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby wrote:

> What could be very helpful here is some education for would-be Django
> developers. The tutorial format has worked so well for educating new Django
> users, why not apply it also to Django developers also? After the 1.2
> release, why don't we come up with a Django developers tutorial that walks
> us through the process of solving issues and working on Django. The goal of
> this would be to help would-be developers understand the Django development
> process by getting their hands dirty with a real issue.
>
> It could begin with a short explanation of the process, go through finding
> a real (old) example issue in Trac (already solved), it could run down what
> type of Trac activity is helpful and what is not. Then the tutorial could
> instruct the reader to checkout an old revision of Django (with the unsolved
> issue) and how to reproduce the issue.
>
> We could show the reader how to apply a bad patch (attached by some
> less-informed Trac user), then how to run the test suite and notice that
> some tests fail. Some instruction on how to politely note that fact on Trac
> might be in order as well as how the patch was rewritten in order to pass
> the tests.
>
> Another bit on proper documentation, some notes on quality, where to get
> help, what types of issues need discussion on this list would be great and
> I'm sure there's more that could be included with this type of tutorial.
>
>
> On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss wrote:
>
>> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
>> > When I finally did submit my first patch, I was terrified of getting
>> > it wrong and having it rejected. I'd seen it happen on other tickets.
>> > It wasn't until I got *more involved* and started keeping up with the
>> > trac timeline--watching the ebb and flow of tickets--that I started to
>> > understand how the tone on trac had a reason. Until you get that
>> > perspective, it's hard to know what's right or wrong, and easy to take
>> > things personally. The core devs can seem imposing or scary simply
>> > because you don't know them.
>>
>> This is *really* good feedback, and thank you very much for it.
>>
>> Clearly scaring people isn't our intent, but if that's the result...
>> well, we're doing something wrong. I really don't want people to be
>> scared off, and I'm hearing from you and a few others that that's
>> already happening.
>>
>> I don't think I need to enumerate why the tone on a ticket tracker
>> tends towards the terse -- lack of time, repetition, yadayada -- but
>> regardless I don't like our process being scary.
>>
>> > If anything, my point is that getting started as a Django contributor
>> > *can* be difficult, and the core team just being aware of that fact is
>> > a good thing.
>>
>> I hear you loud and clear, and I'd love any suggestions you might have
>> about how we might improve in this area.
>>
>> Jacob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected]
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>
>
> --
> Stephen Crosby
> Web Developer
> lithostech.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

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

Re: Process discussion: reboot

2010-04-20 Thread Stephen Crosby

What could be very helpful here is some education for would-be Django
developers. The tutorial format has worked so well for educating new Django
users, why not apply it also to Django developers also? After the 1.2
release, why don't we come up with a Django developers tutorial that walks
us through the process of solving issues and working on Django. The goal of
this would be to help would-be developers understand the Django development
process by getting their hands dirty with a real issue.

It could begin with a short explanation of the process, go through finding a
real (old) example issue in Trac (already solved), it could run down what
type of Trac activity is helpful and what is not. Then the tutorial could
instruct the reader to checkout an old revision of Django (with the unsolved
issue) and how to reproduce the issue.

We could show the reader how to apply a bad patch (attached by some
less-informed Trac user), then how to run the test suite and notice that
some tests fail. Some instruction on how to politely note that fact on Trac
might be in order as well as how the patch was rewritten in order to pass
the tests.

Another bit on proper documentation, some notes on quality, where to get
help, what types of issues need discussion on this list would be great and
I'm sure there's more that could be included with this type of tutorial.

On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss wrote:

> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
> > When I finally did submit my first patch, I was terrified of getting
> > it wrong and having it rejected. I'd seen it happen on other tickets.
> > It wasn't until I got *more involved* and started keeping up with the
> > trac timeline--watching the ebb and flow of tickets--that I started to
> > understand how the tone on trac had a reason. Until you get that
> > perspective, it's hard to know what's right or wrong, and easy to take
> > things personally. The core devs can seem imposing or scary simply
> > because you don't know them.
>
> This is *really* good feedback, and thank you very much for it.
>
> Clearly scaring people isn't our intent, but if that's the result...
> well, we're doing something wrong. I really don't want people to be
> scared off, and I'm hearing from you and a few others that that's
> already happening.
>
> I don't think I need to enumerate why the tone on a ticket tracker
> tends towards the terse -- lack of time, repetition, yadayada -- but
> regardless I don't like our process being scary.
>
> > If anything, my point is that getting started as a Django contributor
> > *can* be difficult, and the core team just being aware of that fact is
> > a good thing.
>
> I hear you loud and clear, and I'd love any suggestions you might have
> about how we might improve in this area.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
Stephen Crosby
Web Developer
lithostech.com

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
> When I finally did submit my first patch, I was terrified of getting
> it wrong and having it rejected. I'd seen it happen on other tickets.
> It wasn't until I got *more involved* and started keeping up with the
> trac timeline--watching the ebb and flow of tickets--that I started to
> understand how the tone on trac had a reason. Until you get that
> perspective, it's hard to know what's right or wrong, and easy to take
> things personally. The core devs can seem imposing or scary simply
> because you don't know them.

This is *really* good feedback, and thank you very much for it.

Clearly scaring people isn't our intent, but if that's the result...
well, we're doing something wrong. I really don't want people to be
scared off, and I'm hearing from you and a few others that that's
already happening.

I don't think I need to enumerate why the tone on a ticket tracker
tends towards the terse -- lack of time, repetition, yadayada -- but
regardless I don't like our process being scary.

> If anything, my point is that getting started as a Django contributor
> *can* be difficult, and the core team just being aware of that fact is
> a good thing.

I hear you loud and clear, and I'd love any suggestions you might have
about how we might improve in this area.

Jacob

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

Re: Process discussion: reboot

2010-04-20 Thread Alex Gaynor

On Tue, Apr 20, 2010 at 11:39 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta  wrote:
>> Having an additional field{s} in the ticket, only accessible to core
>> developers, where they would put the "official" (as in: approved by a
>> core developer) triage status of the ticket, could improve the
>> efficency of the tickets review.
>
> I'm hearing a trend that folks are often confused over what's
> "official" versus "unofficial" in Trac.
>
> However, I'm wary of committer-only fields -- it adds an additional
> burden on us to keep 'em up-to-date, and I don't like the idea of
> preventing people who want to contribute from doing so.
>
> So, what do you think of just adding some sort of different display to
> comments or to ticket changes made by members of the core team? You
> know how on blogs comments by the original author are highlighted?
> Something like that. I think it'd help people know when something
> "official" happened.
>
> Thoughts?
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

In general I don't think that the fields on tickets are nearly as
liable to being inaccurate as people are making it sound.  That said
marking users who are committers or triagers or what not probably
wouldn't hurt.

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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta  wrote:
> Having an additional field{s} in the ticket, only accessible to core
> developers, where they would put the "official" (as in: approved by a
> core developer) triage status of the ticket, could improve the
> efficency of the tickets review.

I'm hearing a trend that folks are often confused over what's
"official" versus "unofficial" in Trac.

However, I'm wary of committer-only fields -- it adds an additional
burden on us to keep 'em up-to-date, and I don't like the idea of
preventing people who want to contribute from doing so.

So, what do you think of just adding some sort of different display to
comments or to ticket changes made by members of the core team? You
know how on blogs comments by the original author are highlighted?
Something like that. I think it'd help people know when something
"official" happened.

Thoughts?

Jacob

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

Re: Process discussion: reboot

2010-04-20 Thread Peter Baumgartner

On Mon, Apr 19, 2010 at 8:19 AM, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>

Jacob, I really think you're hearing from the vocal minority here.
There are plenty of people, myself included, who are very happy with
Django and the current development process. It will never be a perfect
fit for everyone and some will always complain. We've been using
Django professionally for a few years now and it has grown by leaps
and bounds in that time. I'm glad to see that Django is picky about
what is included. Stable growth trumps a kitchen sink worth of
half-baked features any day.

Keep up the amazing work and don't let the naysayers get you down.

-- Pete

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

Re: Process discussion: reboot

2010-04-19 Thread Sean O'Connor

The DVCS conversation has been had many times over the last year or two on
this list and in other places.  I mention this not to say that you should
know already as it isn't clearly documented, but as a suggestion that you
should make sure that you are bringing something new and concrete to the
discussion before starting it again.

The current view of the core team is that the combination of a central,
authoritative, Subversion server with semi-official mirrors for Git,
Mercurial, and Bazaar is sufficient for the foreseeable future.  All of the
benefits of the distributed systems are available via the mirrors and
there's no disruption to users who are used to the current
workflow/infrastructure.

If you would like to make a contribution to Django, you can work with
whichever of the three most common DVCSs and there will be several core devs
able to accept your changes without any problems.


Sean O'Connor
http://seanoc.com

P.S.  I am not a core dev so any of the core devs should feel free to
correct me on this. That being said this view has been clearly expressed
several times on this list and in other venues.


On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche  wrote:

> If you contribute to open source projects, at one point you'll be
> faced with the forced choice to use git. It is extremely popular (I
> believe it's the most popular after svn), and unlike svn it's popular
> for a good reason.
> However, hg is decent as well; whatever the django team chooses, as
> long as it's not cvs it can't really be worse than svn.
>
> (bzr fan, personally, but I'd prefer it if django moved over to git)
>
> J. Leclanche / Adys
>
>
>
> On Tue, Apr 20, 2010 at 2:58 AM, VernonCole  wrote:
> > Not to start a flame war --- but PLEASE! don't use git.  I already
> > have to use the other two leading DVCS's and all three are one too
> > many.
> > I personally prefer bazaar, but python itself and pywin32 are both
> > committed to mercurial.  I suspect that hg would be a better choice
> > for most people.
> > --
> > Vernon Cole
> >
> > On Apr 19, 10:05 am, Dennis Kaarsemaker 
> > wrote:
> >> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
> >>
> >>
> >>
> >>
> >>
> >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:
> >>
> >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry 
> wrote:
> >> > >> One suggestion that jumped out at me (which I admittedly know very
> little
> >> > >> history about with regards to Django or other projects) was the
> "trunk
> >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that
> process might
> >> > >> entail in detail, to determine if it would address any concerns?
> >>
> >> > > FTR, I think this is a fine idea, and I think most (all?) of the
> other
> >> > > Django core developers do, too. It's just waiting on someone to Just
> >> > > Do It.
> >>
> >> > > Anyone -- preferably a group -- who wants to start such a branch
> could
> >> > > go ahead and start one using the DVCS tool of their choice (Django
> has
> >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me
> and
> >> > > I'll start watching it; show some continued motion and I'll spend
> some
> >> > > time getting a buildbot going against the branch; show high quality
> >> > > and I'll start pulling from it more and more frequently; show
> >> > > incredibly quality and I'll suggest that the maintainer(s) get
> commit.
> >>
> >> > >> For my part, I see that it could be helpful to let some
> patches/ideas get a
> >> > >> shot at integration without having to endure the (necessarily) more
> rigorous
> >> > >> core commit trails.
> >>
> >> > > Quality is important, and if this branch is created it needs to
> >> > > maintain that quality. If this hypothetical branch is low-quality
> it's
> >> > > just a different tool for a queue of un-reviewed patches, and I've
> >> > > already got one of those. I'm not willing to compromise on quality:
> if
> >> > > patches don't meet our standards, they don't go in.
> >>
> >> > > Jacob
> >>
> >> > I fully agree regarding quality, my point being that this branch
> itself may
> >> > not be "trunk ready" at any given time, but patches/pulls from it
> would be;
> >> > quality of patches would obviously need to meet existing standards.
> Perhaps
> >> > that distinction isn't helpful, necessary, or desirable.
> >>
> >> I've been thinking of starting a proper contribution in django in a
> >> similar way: a github repo with per-ticket branches that are trunk-ready
> >> and regularly updated (rebased) against trunk until they are applied.
> >>
> >> So far I've only done so for a pony of mine as a test, but as soon as
> >> the ash cloud clears, I will look at existing tickets. Would this
> >> approach be useful for core committers to pull patches from?
> >>
> >> --
> >> Dennis K.
> >>
> >> They've gone to plaid!
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "Django developers" group.
> >> To post to

Re: Process discussion: reboot

2010-04-19 Thread Jerome Leclanche

If you contribute to open source projects, at one point you'll be
faced with the forced choice to use git. It is extremely popular (I
believe it's the most popular after svn), and unlike svn it's popular
for a good reason.
However, hg is decent as well; whatever the django team chooses, as
long as it's not cvs it can't really be worse than svn.

(bzr fan, personally, but I'd prefer it if django moved over to git)

J. Leclanche / Adys



On Tue, Apr 20, 2010 at 2:58 AM, VernonCole  wrote:
> Not to start a flame war --- but PLEASE! don't use git.  I already
> have to use the other two leading DVCS's and all three are one too
> many.
> I personally prefer bazaar, but python itself and pywin32 are both
> committed to mercurial.  I suspect that hg would be a better choice
> for most people.
> --
> Vernon Cole
>
> On Apr 19, 10:05 am, Dennis Kaarsemaker 
> wrote:
>> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
>>
>>
>>
>>
>>
>> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:
>>
>> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  
>> > > wrote:
>> > >> One suggestion that jumped out at me (which I admittedly know very 
>> > >> little
>> > >> history about with regards to Django or other projects) was the "trunk
>> > >> ready" branch(es) [1]. Perhaps an effort to outline what that process 
>> > >> might
>> > >> entail in detail, to determine if it would address any concerns?
>>
>> > > FTR, I think this is a fine idea, and I think most (all?) of the other
>> > > Django core developers do, too. It's just waiting on someone to Just
>> > > Do It.
>>
>> > > Anyone -- preferably a group -- who wants to start such a branch could
>> > > go ahead and start one using the DVCS tool of their choice (Django has
>> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
>> > > I'll start watching it; show some continued motion and I'll spend some
>> > > time getting a buildbot going against the branch; show high quality
>> > > and I'll start pulling from it more and more frequently; show
>> > > incredibly quality and I'll suggest that the maintainer(s) get commit.
>>
>> > >> For my part, I see that it could be helpful to let some patches/ideas 
>> > >> get a
>> > >> shot at integration without having to endure the (necessarily) more 
>> > >> rigorous
>> > >> core commit trails.
>>
>> > > Quality is important, and if this branch is created it needs to
>> > > maintain that quality. If this hypothetical branch is low-quality it's
>> > > just a different tool for a queue of un-reviewed patches, and I've
>> > > already got one of those. I'm not willing to compromise on quality: if
>> > > patches don't meet our standards, they don't go in.
>>
>> > > Jacob
>>
>> > I fully agree regarding quality, my point being that this branch itself may
>> > not be "trunk ready" at any given time, but patches/pulls from it would be;
>> > quality of patches would obviously need to meet existing standards. Perhaps
>> > that distinction isn't helpful, necessary, or desirable.
>>
>> I've been thinking of starting a proper contribution in django in a
>> similar way: a github repo with per-ticket branches that are trunk-ready
>> and regularly updated (rebased) against trunk until they are applied.
>>
>> So far I've only done so for a pony of mine as a test, but as soon as
>> the ash cloud clears, I will look at existing tickets. Would this
>> approach be useful for core committers to pull patches from?
>>
>> --
>> Dennis K.
>>
>> They've gone to plaid!
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to 
>> [email protected].
>> For more options, visit this group 
>> athttp://groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Process discussion: reboot

2010-04-19 Thread VernonCole

Not to start a flame war --- but PLEASE! don't use git.  I already
have to use the other two leading DVCS's and all three are one too
many.
I personally prefer bazaar, but python itself and pywin32 are both
committed to mercurial.  I suspect that hg would be a better choice
for most people.
--
Vernon Cole

On Apr 19, 10:05 am, Dennis Kaarsemaker 
wrote:
> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
>
>
>
>
>
> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:
>
> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  
> > > wrote:
> > >> One suggestion that jumped out at me (which I admittedly know very little
> > >> history about with regards to Django or other projects) was the "trunk
> > >> ready" branch(es) [1]. Perhaps an effort to outline what that process 
> > >> might
> > >> entail in detail, to determine if it would address any concerns?
>
> > > FTR, I think this is a fine idea, and I think most (all?) of the other
> > > Django core developers do, too. It's just waiting on someone to Just
> > > Do It.
>
> > > Anyone -- preferably a group -- who wants to start such a branch could
> > > go ahead and start one using the DVCS tool of their choice (Django has
> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
> > > I'll start watching it; show some continued motion and I'll spend some
> > > time getting a buildbot going against the branch; show high quality
> > > and I'll start pulling from it more and more frequently; show
> > > incredibly quality and I'll suggest that the maintainer(s) get commit.
>
> > >> For my part, I see that it could be helpful to let some patches/ideas 
> > >> get a
> > >> shot at integration without having to endure the (necessarily) more 
> > >> rigorous
> > >> core commit trails.
>
> > > Quality is important, and if this branch is created it needs to
> > > maintain that quality. If this hypothetical branch is low-quality it's
> > > just a different tool for a queue of un-reviewed patches, and I've
> > > already got one of those. I'm not willing to compromise on quality: if
> > > patches don't meet our standards, they don't go in.
>
> > > Jacob
>
> > I fully agree regarding quality, my point being that this branch itself may
> > not be "trunk ready" at any given time, but patches/pulls from it would be;
> > quality of patches would obviously need to meet existing standards. Perhaps
> > that distinction isn't helpful, necessary, or desirable.
>
> I've been thinking of starting a proper contribution in django in a
> similar way: a github repo with per-ticket branches that are trunk-ready
> and regularly updated (rebased) against trunk until they are applied.
>
> So far I've only done so for a pony of mine as a test, but as soon as
> the ash cloud clears, I will look at existing tickets. Would this
> approach be useful for core committers to pull patches from?
>
> --
> Dennis K.
>
> They've gone to plaid!
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

2010-04-19 Thread George Vilches


On Apr 19, 2010, at 5:16 PM, Mike wrote:

> For the project of such exposure as Django the number of _active_ core
> members that actually do work on trunk and are participating in the
> decision making process is extremely small. Quick and dirty statistic
> on
> trunk commits shows that more than 75% of the work in _trunk_  is done
> by just 4 developers [1] and from this list it seems that not much
> more are
> really involved into design decision making either.

It does appear true that we're a little light on active core devs right now.  
Can I propose Alex Gaynor for commit bit?  Seriously, why hasn't someone else 
proposed this already? :)

George

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

Re: Process discussion: reboot

2010-04-19 Thread Don Guernsey

Once I understand what I am doing I would have no problem putting together
an "ebb and flow" diagram with pointers to codesomething like...Step 1
Request Made--When a request is made the first thing that happens is def
AutoStart is activated, next, def SecondStart is fired (with pictures).

On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta  wrote:

> On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss 
> wrote:
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> My understanding is that write access to triage stage and tickets
> details is granted to everybody (even to anonymous users), and
> everybody can change everything, thus making this data not 100%
> reliable.
>
> Having an additional field{s} in the ticket, only accessible to core
> developers, where they would put the "official" (as in: approved by a
> core developer) triage status of the ticket, could improve the
> efficency of the tickets review.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

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

Re: Process discussion: reboot

2010-04-19 Thread Mike

On Apr 19, 10:19 am, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>

I'm new in Django so you can just ignore my opinion but probably due
to
a fresh eye I think I see _one_ important reason why such discussions
pop up over and over again.

For the project of such exposure as Django the number of _active_ core
members that actually do work on trunk and are participating in the
decision making process is extremely small. Quick and dirty statistic
on
trunk commits shows that more than 75% of the work in _trunk_  is done
by just 4 developers [1] and from this list it seems that not much
more are
really involved into design decision making either.

At the same time the requirements for any new proposal are extremely
high. You and Russ have explained them many times on this list. in
short
it should be perfect from the core view to be included.

I'm not saying it is good or bad. No judgment at all. Just pure
observation.

These two things simply mean that for the core team it is just
_physically_
impossible to cope with the rising flow of requests/patches/bug
reports.

IMHO there are two ways out of this :

1. Share responsibility and ownership with more developers even if
their
views are not exactly match yours.

2. Just ignore such discussions, they are inevitable, unless you'll
make
this list moderated.

Regards,
Mike

[1] Number of commits and changed lines per developer for the
 tr...@13001:

#  #Comm   %Cum%  #Lines  %Cum%   developer
---
 1. 2612 31.48  31.48  2626 17.53  17.53  adrian
 2. 1814 21.86  53.34  5595 37.34  54.87  mtredinnick
 3. 1026 12.37  65.71  1400  9.34  64.21  russellm
 4.  818  9.86  75.57  1235  8.24  72.46  jacob
 5.  335  4.04  79.61   760  5.07  77.53  gwilson
 6.  202  2.43  82.04   402  2.68  80.21  hugo
 7.  201  2.42  84.46   472  3.15  83.36  kmtracey
 8.  186  2.24  86.71   779  5.20  88.56  lukeplant
 9.  185  2.23  88.94   285  1.90  90.46  ubernostrum
10.  183  2.21  91.14   398  2.66  93.12  jbronn
11.  170  2.05  93.19   183  1.22  94.34  jezdez
12.  144  1.74  94.93   209  1.39  95.74  brosner
13.   73  0.88  95.8199  0.66  96.40  telenieko
14.   68  0.82  96.6394  0.63  97.02  ikelly
15.   67  0.81  97.4379  0.53  97.55  jkocherhans
16.   44  0.53  97.9675  0.50  98.05  wilson
17.   39  0.47  98.4378  0.52  98.57  zgoda
18.   34  0.41  98.8464  0.43  99.00  mboersma
19.   32  0.39  99.2360  0.40  99.40  tekNico
20.   25  0.30  99.5325  0.17  99.57  simon
21.   14  0.17  99.7024  0.16  99.73  toxik
22.   11  0.13  99.8318  0.12  99.85  ramiro
23.8  0.10  99.9315  0.10  99.95  aljosa
24.5  0.06  99.99 7  0.05  99.99  garcia_marc
25.1  0.01 100.00 1  0.01 100.00  jtauber

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

Re: Process discussion: reboot

2010-04-19 Thread Bmheight

I have to agree with Gabriel here as I to have only recently been trying to
actively participate in the growing experience that is Django. Though I
haven't quite yet made the jump into actually contributing code yet as I'm
still coming to terms with understanding the internals of both the code and
the community. Though I am not a contributor to Django I watch the mailing
lists closely and try to use the discussions to help me build up my own
knowledge of the internals of both how the community works as well as how
Django itself evolves. This may be a developers discussion list but there
are some of us actively watching these threads who find it quite scary when
a 'policy change' discussion becomes a main focus on a framework that holds
a lot of peoples futures in the balance. My 2 cents.

I too will close with the very same Benjamin Franklin quote that Gabriel
previously posted, as it is a very relevant situation:

"We must hang together or assuredly we shall hang separately.""

On Mon, Apr 19, 2010 at 1:34 PM, Gabriel Hurley  wrote:

> Before I even say anything: I think the core team does a great job,
> they're as fair as humanly possible in their decisions, and Django's
> stability is amazing.
>
> My disclaimer out of the way, I'd like to share my own experience of
> being a new contributor just to add another perspective.
>
> I only started submitting patches during the 1.2 release cycle, so I'm
> still a relative newbie. In 4 months I've learned *a lot* about
> Django's process and the history of thought behind many of the issues
> in both the codebase and the development process. But that knowledge
> wasn't easy to come by.
>
> I read the contributing docs twice before I even opened my first
> ticket. Twice more before I submitted a single patch.
>
> When I finally did submit my first patch, I was terrified of getting
> it wrong and having it rejected. I'd seen it happen on other tickets.
> It wasn't until I got *more involved* and started keeping up with the
> trac timeline--watching the ebb and flow of tickets--that I started to
> understand how the tone on trac had a reason. Until you get that
> perspective, it's hard to know what's right or wrong, and easy to take
> things personally. The core devs can seem imposing or scary simply
> because you don't know them.
>
> Even after reading the contributing docs and all the internals several
> times, there was still a large portion of knowledge that I found only
> existed outside those docs. Spending hours reading through this list's
> history and through the #django-dev IRC logs have answered a lot more
> of my questions. While it might seem obvious to say "go add that
> information to the docs" the truth is that a lot of what new
> contributors need to learn is subjective, and may not belong in
> official documentation.
>
> I did find that the ambiguity of ticket statuses in trac made it hard
> to dive right in and understand what was going on. But that's been
> discussed at length. When someone has an idea for a solution there,
> I'll be the first to jump in and work on it.
>
> If anything, my point is that getting started as a Django contributor
> *can* be difficult, and the core team just being aware of that fact is
> a good thing.
>
> That said, I have no sympathy for the malcontents. I would really
> rather have seen 1.2 get released than 80+ messages on these two
> threads. If complaints were patches, we'd be halfway to 1.3 by now.
>
> Divisiveness and ill-willed argument is stifling to creativity and
> progress. I hope this post doesn't contribute to it.
>
> I'll close with Benjamin Franklin: "We must hang together or assuredly
> we shall hang separately."
>
>   - Gabriel
>
>
>
> On Apr 19, 7:19 am, Jacob Kaplan-Moss  wrote:
> > Hi folks --
> >
> > I'd like to try to reboot the discussion that's been going on about
> > Django's development process.
> >
> > I'm finding the current thread incredibly demoralizing: there's a
> > bunch of frustration being expressed, and I hear that, but I'm having
> > trouble finding any concrete suggestions. Instead, the thread has
> > devolved into just going around in circles on the same small handful
> > of issues.
> >
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
> >
> > Jacob
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> [email protected]
> .
> > For more options, visit this group athttp://
> groups.google.com/group/django-developers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups

Re: Process discussion: reboot

2010-04-19 Thread Gabriel Hurley

Before I even say anything: I think the core team does a great job,
they're as fair as humanly possible in their decisions, and Django's
stability is amazing.

My disclaimer out of the way, I'd like to share my own experience of
being a new contributor just to add another perspective.

I only started submitting patches during the 1.2 release cycle, so I'm
still a relative newbie. In 4 months I've learned *a lot* about
Django's process and the history of thought behind many of the issues
in both the codebase and the development process. But that knowledge
wasn't easy to come by.

I read the contributing docs twice before I even opened my first
ticket. Twice more before I submitted a single patch.

When I finally did submit my first patch, I was terrified of getting
it wrong and having it rejected. I'd seen it happen on other tickets.
It wasn't until I got *more involved* and started keeping up with the
trac timeline--watching the ebb and flow of tickets--that I started to
understand how the tone on trac had a reason. Until you get that
perspective, it's hard to know what's right or wrong, and easy to take
things personally. The core devs can seem imposing or scary simply
because you don't know them.

Even after reading the contributing docs and all the internals several
times, there was still a large portion of knowledge that I found only
existed outside those docs. Spending hours reading through this list's
history and through the #django-dev IRC logs have answered a lot more
of my questions. While it might seem obvious to say "go add that
information to the docs" the truth is that a lot of what new
contributors need to learn is subjective, and may not belong in
official documentation.

I did find that the ambiguity of ticket statuses in trac made it hard
to dive right in and understand what was going on. But that's been
discussed at length. When someone has an idea for a solution there,
I'll be the first to jump in and work on it.

If anything, my point is that getting started as a Django contributor
*can* be difficult, and the core team just being aware of that fact is
a good thing.

That said, I have no sympathy for the malcontents. I would really
rather have seen 1.2 get released than 80+ messages on these two
threads. If complaints were patches, we'd be halfway to 1.3 by now.

Divisiveness and ill-willed argument is stifling to creativity and
progress. I hope this post doesn't contribute to it.

I'll close with Benjamin Franklin: "We must hang together or assuredly
we shall hang separately."

   - Gabriel

On Apr 19, 7:19 am, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

2010-04-19 Thread Giuseppe Ciotta

On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss  wrote:

> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.

My understanding is that write access to triage stage and tickets
details is granted to everybody (even to anonymous users), and
everybody can change everything, thus making this data not 100%
reliable.

Having an additional field{s} in the ticket, only accessible to core
developers, where they would put the "official" (as in: approved by a
core developer) triage status of the ticket, could improve the
efficency of the tickets review.

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 12:24 PM, orokusaki  wrote:
> Jacob, I just refreshed. Please don't kick me. I'm trying to have a
> dialogue, and I'm not trolling. Django is my life, and I want to help.

Then prove it.

Ball's in your court.

Jacob

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 12:23 PM, orokusaki  wrote:
> --  No matter what industry you're in, or what your title is, your
> real job is "Sales Person". Your second job is "Customer Service", and
> finally your third job is "[Insert Job Title Here]".

Dammit, this isn't my job -- it's my fucking hobby.

The only way anything gets done here is if people volunteer and do it.

> I'm not saying that the core developers should think of their free,
> public contributions as a paying client, but it might be good to
> exercise a little restraint when you feel "annoyed".

You have absolutely no idea the level of restraint I'm showing.

> If I didn't feel
> so pushed back by the core team, I'd become a big contributor, but
> instead of writing code, I spend all of my free time arguing,

Than STOP ARGUING AND WRITE SOME CODE!

Jacob

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

Re: Process discussion: reboot

Jacob, I just refreshed. Please don't kick me. I'm trying to have a
dialogue, and I'm not trolling. Django is my life, and I want to help.

On Apr 19, 11:20 am, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 19, 2010 at 12:09 PM, orokusaki  wrote:
> > Firstly, thanks to Jacob for the highly hostile nature of his bedside
> > manor.
>
> Please, just stop. This doesn't help.
>
> > Secondly, I didn't assert anything. I merely referenced the docs (I
> > suppose this will be another case where you simply adjust the docs to
> > mirror your recent assertion)
>
> Now you're trolling - we've never done this. The documentation is in
> SVN and there's a complete historical record. Point to one instance
> where we've done this.
>
> This is your last warning. Keep this up and I'm going to have no
> choice but to kick you off this list.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

On a broader note, let me give you a bit of history.

I started my career as a customer service person. I managed Staples
Business Services department in my local Staples. Before I decided to
learn programming a couple years ago at 24, I learned a valuable
lesson:

-- No matter what industry you're in, or what your title is, your
real job is "Sales Person". Your second job is "Customer Service", and
finally your third job is "[Insert Job Title Here]".

When my clients come to me and say "MY SITE SHOULD DO THIS!" my first
response isn't "YOU'RE WRONG!". I understand that they're my clients,
and they are always right in their own eyes. It's my job to find out
where their pain point is, and see if there is a better remedy than
what they're suggesting. If there is not, then it's my job to decide
if they're truly wrong. If I find out they're not wrong, and I don't
have a better remedy, I typically cave to their request rather than
going back and changing my proposal to exclude their current request.

I'm not saying that the core developers should think of their free,
public contributions as a paying client, but it might be good to
exercise a little restraint when you feel "annoyed". If I didn't feel
so pushed back by the core team, I'd become a big contributor, but
instead of writing code, I spend all of my free time arguing, if just
to get somebody to level with me and give me a good reason why they're
turning my away. I don't claim to be an expert, but in my own eyes, my
ideas are gold until somebody can give me a good explanation of why
they're not.

In the team development process, this constructive feedback is called
problem solving. Look at what I was able to achieve in 5 minutes with
James' feedback:
http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/1397a0785cb09a36
(bottom).

If my new version is still bad, take 30 seconds for some more
feedback. repeat this across a slough of tickets, and before you know
it you have hundreds of problem solvers like me, with vested
interests, developing Django piece by piece.

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

Re: Process discussion: reboot

2010-04-19 Thread James Bennett

On Mon, Apr 19, 2010 at 12:09 PM, orokusaki  wrote:
> Firstly, thanks to Jacob for the highly hostile nature of his bedside
> manor.
>
> Secondly, I didn't assert anything. I merely referenced the docs (I
> suppose this will be another case where you simply adjust the docs to
> mirror your recent assertion)

Strike one was your behavior in this thread:

http://groups.google.com/group/django-developers/browse_thread/thread/b888734b05878f87/

Your behavior in this thread is now strike two.

Be thankful that America's national pastime allows for three strikes,
because if I weren't a baseball fan I'd be all for you being out
already.


-- 
"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 [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 12:09 PM, orokusaki  wrote:
> Firstly, thanks to Jacob for the highly hostile nature of his bedside
> manor.

Please, just stop. This doesn't help.

> Secondly, I didn't assert anything. I merely referenced the docs (I
> suppose this will be another case where you simply adjust the docs to
> mirror your recent assertion)

Now you're trolling - we've never done this. The documentation is in
SVN and there's a complete historical record. Point to one instance
where we've done this.

This is your last warning. Keep this up and I'm going to have no
choice but to kick you off this list.

Jacob

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

Re: Process discussion: reboot

Firstly, thanks to Jacob for the highly hostile nature of his bedside
manor.

Secondly, I didn't assert anything. I merely referenced the docs (I
suppose this will be another case where you simply adjust the docs to
mirror your recent assertion)


http://docs.djangoproject.com/en/dev/misc/api-stability/#api-stability



On Apr 19, 10:48 am, David Zhou  wrote:
> On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss  
> wrote:
> > On Mon, Apr 19, 2010 at 10:38 AM, David Zhou  wrote:
> >> The specific number of point releases to remain compatible with can
> >> probably be quibbled over, but I think the point is that maintaining
> >> across the entirety of 1.x releases when point releases take this long
> >> can be untenable for good forward momentum.
>
> > I'm pretty annoyed that you think that the policy is to maintain
> > backwards compatibility "across the entirety of 1.x releases" because,
> > well, that's not the policy. This is documented; see
> >http://docs.djangoproject.com/en/dev/internals/release-process/.
>
> You're right, of course, and I should've fact checked orokusaki's
> assertion that that was the current policy.  So I'll retract my
> previous statements -- those are only applicable given the policy
> stated in orokusaki's email.
>
> -- dz
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

2010-04-19 Thread David Zhou

On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 19, 2010 at 10:38 AM, David Zhou  wrote:
>> The specific number of point releases to remain compatible with can
>> probably be quibbled over, but I think the point is that maintaining
>> across the entirety of 1.x releases when point releases take this long
>> can be untenable for good forward momentum.
>
> I'm pretty annoyed that you think that the policy is to maintain
> backwards compatibility "across the entirety of 1.x releases" because,
> well, that's not the policy. This is documented; see
> http://docs.djangoproject.com/en/dev/internals/release-process/.

You're right, of course, and I should've fact checked orokusaki's
assertion that that was the current policy.  So I'll retract my
previous statements -- those are only applicable given the policy
stated in orokusaki's email.

-- dz

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 11:05 AM, Dennis Kaarsemaker
 wrote:
> I've been thinking of starting a proper contribution in django in a
> similar way: a github repo with per-ticket branches that are trunk-ready
> and regularly updated (rebased) against trunk until they are applied.
>
> So far I've only done so for a pony of mine as a test, but as soon as
> the ash cloud clears, I will look at existing tickets. Would this
> approach be useful for core committers to pull patches from?

If the quality's good, yes -- very much so.

Jacob

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 10:38 AM, David Zhou  wrote:
> The specific number of point releases to remain compatible with can
> probably be quibbled over, but I think the point is that maintaining
> across the entirety of 1.x releases when point releases take this long
> can be untenable for good forward momentum.

I'm pretty annoyed that you think that the policy is to maintain
backwards compatibility "across the entirety of 1.x releases" because,
well, that's not the policy. This is documented; see
http://docs.djangoproject.com/en/dev/internals/release-process/.
Quoting from there:

"""
Minor release (1.1, 1.2, etc.) [...] will contain new features,
improvements to existing features, and such. A minor release may
deprecate certain features from previous releases. If a feature in
version A.B is deprecated, it will continue to work in version A.B+1.
In version A.B+2, use of the feature will raise a DeprecationWarning
but will continue to work. Version A.B+3 will remove the feature
entirely.

So, for example, if we decided to remove a function that existed in Django 1.0:

Django 1.1 will contain a backwards-compatible replica of the function
which will raise a PendingDeprecationWarning. This warning is silent
by default; you need to explicitly turn on display of these warnings.
Django 1.2 will contain the backwards-compatible replica, but the
warning will be promoted to a full-fledged DeprecationWarning. This
warning is loud by default, and will likely be quite annoying.
Django 1.3 will remove the feature outright.
"""

So, yes, we're really *are* just quibbling over the specific number of
releases that Django will be compatible with. A few people want just
one stable release, but the core committers want two.

So here's where I put on by BDFL hat: Django's backwards-compability
policy will remain as quoted above.

You think I'm wrong, and that's fine, and I don't expect to convince
you otherwise. But ultimately it's my decision to make, and I'm making
it.

But for the record, I will explain why I feel so strongly about this:

The best part of my job is that I get to talk to and meet so many
people who're using Django. These folks span the glove, and they also
span the gamut of software developers. In the last year, I've spoken
to design agencies, data visualization companies, cloud computing
experts, Enterprise IT developers, web 2.0 developers, web 1.0
developers, new media, old media, startups, Fortune 500 CTOs, venture
capitalists, angel investors, bankers, attorneys, financial advisors,
firemen, and more.

The recurring theme -- the thing I hear over, and over, and over again
-- is how much they love Django's stability and predictability. Over
and over again I hear that software maintenance is a pain in the ass,
and that Django makes it easier. If upgrades from 1.1 to 1.2 aren't
easy, these developers tell me, then they won't be able to take
advantage of new features.

My evidence goes beyond anecdotal. Studies have shown that as much as
80% of software work is in maintenance, and, further, that much of
that maintenance work is non-corrective (i.e. adding features).

When software changes dramatically between releases, people get stuck
on old versions, and this means they're unable to develop the features
they need.

So, once again, the policy will not change unless you can demonstrate
overwhelming evidence that I am wrong.

Jacob

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

Re: Process discussion: reboot

2010-04-19 Thread Dennis Kaarsemaker

On ma, 2010-04-19 at 15:47 +, Peter Landry wrote:
> 
> 
> On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:
> 
> > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  wrote:
> >> One suggestion that jumped out at me (which I admittedly know very little
> >> history about with regards to Django or other projects) was the "trunk
> >> ready" branch(es) [1]. Perhaps an effort to outline what that process might
> >> entail in detail, to determine if it would address any concerns?
> > 
> > FTR, I think this is a fine idea, and I think most (all?) of the other
> > Django core developers do, too. It's just waiting on someone to Just
> > Do It.
> > 
> > Anyone -- preferably a group -- who wants to start such a branch could
> > go ahead and start one using the DVCS tool of their choice (Django has
> > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
> > I'll start watching it; show some continued motion and I'll spend some
> > time getting a buildbot going against the branch; show high quality
> > and I'll start pulling from it more and more frequently; show
> > incredibly quality and I'll suggest that the maintainer(s) get commit.
> > 
> >> For my part, I see that it could be helpful to let some patches/ideas get a
> >> shot at integration without having to endure the (necessarily) more 
> >> rigorous
> >> core commit trails.
> > 
> > Quality is important, and if this branch is created it needs to
> > maintain that quality. If this hypothetical branch is low-quality it's
> > just a different tool for a queue of un-reviewed patches, and I've
> > already got one of those. I'm not willing to compromise on quality: if
> > patches don't meet our standards, they don't go in.
> > 
> > Jacob
> 
> I fully agree regarding quality, my point being that this branch itself may
> not be "trunk ready" at any given time, but patches/pulls from it would be;
> quality of patches would obviously need to meet existing standards. Perhaps
> that distinction isn't helpful, necessary, or desirable.

I've been thinking of starting a proper contribution in django in a
similar way: a github repo with per-ticket branches that are trunk-ready
and regularly updated (rebased) against trunk until they are applied.

So far I've only done so for a pony of mine as a test, but as soon as
the ash cloud clears, I will look at existing tickets. Would this
approach be useful for core committers to pull patches from?

-- 
Dennis K.

They've gone to plaid!

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

Re: Process discussion: reboot

2010-04-19 Thread Peter Landry




On 4/19/10 11:41 AM, "Jacob Kaplan-Moss"  wrote:

> On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  wrote:
>> One suggestion that jumped out at me (which I admittedly know very little
>> history about with regards to Django or other projects) was the "trunk
>> ready" branch(es) [1]. Perhaps an effort to outline what that process might
>> entail in detail, to determine if it would address any concerns?
> 
> FTR, I think this is a fine idea, and I think most (all?) of the other
> Django core developers do, too. It's just waiting on someone to Just
> Do It.
> 
> Anyone -- preferably a group -- who wants to start such a branch could
> go ahead and start one using the DVCS tool of their choice (Django has
> semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
> I'll start watching it; show some continued motion and I'll spend some
> time getting a buildbot going against the branch; show high quality
> and I'll start pulling from it more and more frequently; show
> incredibly quality and I'll suggest that the maintainer(s) get commit.
> 
>> For my part, I see that it could be helpful to let some patches/ideas get a
>> shot at integration without having to endure the (necessarily) more rigorous
>> core commit trails.
> 
> Quality is important, and if this branch is created it needs to
> maintain that quality. If this hypothetical branch is low-quality it's
> just a different tool for a queue of un-reviewed patches, and I've
> already got one of those. I'm not willing to compromise on quality: if
> patches don't meet our standards, they don't go in.
> 
> Jacob

I fully agree regarding quality, my point being that this branch itself may
not be "trunk ready" at any given time, but patches/pulls from it would be;
quality of patches would obviously need to meet existing standards. Perhaps
that distinction isn't helpful, necessary, or desirable.

Peter

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

Re: Process discussion: reboot

Yes, thank you David.


On Apr 19, 9:38 am, David Zhou  wrote:
> On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss  
> wrote:
> > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki  
> > wrote:
> >> The release of Django 1.0 comes with a promise of API stability and
> >> forwards-compatibility. In a nutshell, this means that code you
> >> develop against Django 1.0 will continue to work against 1.1
> >> unchanged, and you should need to make only minor changes for the 1.2
> >> release.
>
> > So you're proposing that 1.2 be the last backwards-compatible release,
> > and that 1.3 be incompatible (if necessary) with 1.2?
>
> I think he's saying that 1.3 will work with 1.2 but not (necessarily)
> with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0.
>
> The specific number of point releases to remain compatible with can
> probably be quibbled over, but I think the point is that maintaining
> across the entirety of 1.x releases when point releases take this long
> can be untenable for good forward momentum.
>
> -- dz
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry  wrote:
> One suggestion that jumped out at me (which I admittedly know very little
> history about with regards to Django or other projects) was the "trunk
> ready" branch(es) [1]. Perhaps an effort to outline what that process might
> entail in detail, to determine if it would address any concerns?

FTR, I think this is a fine idea, and I think most (all?) of the other
Django core developers do, too. It's just waiting on someone to Just
Do It.

Anyone -- preferably a group -- who wants to start such a branch could
go ahead and start one using the DVCS tool of their choice (Django has
semi-official clones on Github, Bitbucket, and Launchpad). Tell me and
I'll start watching it; show some continued motion and I'll spend some
time getting a buildbot going against the branch; show high quality
and I'll start pulling from it more and more frequently; show
incredibly quality and I'll suggest that the maintainer(s) get commit.

> For my part, I see that it could be helpful to let some patches/ideas get a
> shot at integration without having to endure the (necessarily) more rigorous
> core commit trails.

Quality is important, and if this branch is created it needs to
maintain that quality. If this hypothetical branch is low-quality it's
just a different tool for a queue of un-reviewed patches, and I've
already got one of those. I'm not willing to compromise on quality: if
patches don't meet our standards, they don't go in.

Jacob

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

Re: Process discussion: reboot

Absolutely not. I'm saying the following:

1.1 works with 1.0

1.2 works with 1.1

1.3 works with 1.2


and


1.2 works (with slight modifications) with 1.0

1.3 works (with slight modifications) with 1.1

1.4 works (with slight modifications) with 1.2


On Apr 19, 9:31 am, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 19, 2010 at 10:19 AM, orokusaki  wrote:
> > The release of Django 1.0 comes with a promise of API stability and
> > forwards-compatibility. In a nutshell, this means that code you
> > develop against Django 1.0 will continue to work against 1.1
> > unchanged, and you should need to make only minor changes for the 1.2
> > release.
>
> So you're proposing that 1.2 be the last backwards-compatible release,
> and that 1.3 be incompatible (if necessary) with 1.2?
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected].
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

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

Re: Process discussion: reboot

2010-04-19 Thread David Zhou

On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss  wrote:
> On Mon, Apr 19, 2010 at 10:19 AM, orokusaki  wrote:
>> The release of Django 1.0 comes with a promise of API stability and
>> forwards-compatibility. In a nutshell, this means that code you
>> develop against Django 1.0 will continue to work against 1.1
>> unchanged, and you should need to make only minor changes for the 1.2
>> release.
>
> So you're proposing that 1.2 be the last backwards-compatible release,
> and that 1.3 be incompatible (if necessary) with 1.2?

I think he's saying that 1.3 will work with 1.2 but not (necessarily)
with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0.

The specific number of point releases to remain compatible with can
probably be quibbled over, but I think the point is that maintaining
across the entirety of 1.x releases when point releases take this long
can be untenable for good forward momentum.

-- dz

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

Re: Process discussion: reboot

On Mon, Apr 19, 2010 at 10:19 AM, orokusaki  wrote:
> The release of Django 1.0 comes with a promise of API stability and
> forwards-compatibility. In a nutshell, this means that code you
> develop against Django 1.0 will continue to work against 1.1
> unchanged, and you should need to make only minor changes for the 1.2
> release.

So you're proposing that 1.2 be the last backwards-compatible release,
and that 1.3 be incompatible (if necessary) with 1.2?

Jacob

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

Re: Process discussion: reboot

CURRENT VERSION OF API STABILITY POLICY:

The release of Django 1.0 comes with a promise of API stability and
forwards-compatibility. In a nutshell, this means that code you
develop against Django 1.0 will continue to work against 1.1
unchanged, and you should need to make only minor changes for any 1.X
release.



SUGGESTED VERSION OF API STABILITY POLICY:

The release of Django 1.0 comes with a promise of API stability and
forwards-compatibility. In a nutshell, this means that code you
develop against Django 1.0 will continue to work against 1.1
unchanged, and you should need to make only minor changes for the 1.2
release.



It seems that this small change alone could dramatically decrease the
number of hours spent by you guys.

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

Re: Process discussion: reboot

2010-04-19 Thread Tom Evans

On Mon, Apr 19, 2010 at 3:54 PM, Peter Landry  wrote:
> On 4/19/10 10:19 AM, "Jacob Kaplan-Moss"  wrote:
>
>> Hi folks --
>>
>> I'd like to try to reboot the discussion that's been going on about
>> Django's development process.
>>
>> I'm finding the current thread incredibly demoralizing: there's a
>> bunch of frustration being expressed, and I hear that, but I'm having
>> trouble finding any concrete suggestions. Instead, the thread has
>> devolved into just going around in circles on the same small handful
>> of issues.
>>
>> So: here's your chance. You have suggestions about Django's
>> development process? Make them. I'm listening.
>>
>> Jacob
>
> One suggestion that jumped out at me (which I admittedly know very little
> history about with regards to Django or other projects) was the "trunk
> ready" branch(es) [1]. Perhaps an effort to outline what that process might
> entail in detail, to determine if it would address any concerns?
>
> For my part, I see that it could be helpful to let some patches/ideas get a
> shot at integration without having to endure the (necessarily) more rigorous
> core commit trails.
>
> I'm not really comfortable suggesting any concrete plans for how that might
> happen though. A single almost-trunk branch? A branch per
> lieutenant/component? I'm wary of adding too much bureaucracy and overhead.
> I think it's pretty clear that the core Django process is successful, and
> this seems like a low impact (though potentially high effort?) way to
> involve more of the community.
>
> Peter
>
> [1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b
>

People only talk about a trunk-ready branch if they treat trunk as
some sort of continually updated, always correct, release branch. IMHO
trunk is where you commit features you want to be released, and you
deal with fallout on trunk - you can always revert changes.

An example of something that should have been committed to trunk
already (immediately following release of django 1.1 imo) is custom
FilterSpecs, #5833. This has been pushed from releases for 3 years,
first from 1.0, then 1.1, now 1.2 - all for a feature that should be
available in the admin.

This is a ticket that displays a lot of the issues discussed in the
other thread. The patch is feature complete, and community members
have been updating it to recent versions of django for 3 years. It has
comments of (seemingly) approval from core comitters, but lacks
documentation and tests, and so sits, dead in the water, missing
another release.

A system that works on other projects is a mentorship system. I'm sure
you have had lots of applicants to take part in GSoC - how about
recruiting some of the rejected proposals and have them work through
tickets like this, triaging and polishing to a committable state, at
which point they coordinate with their mentor to have it committed.
Obviously, they'd have to want to do this for free...

One thing is true, the status quo doesn't seem to be resolving these
forgotten tickets.

Cheers

Tom

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

Re: Process discussion: reboot

2010-04-19 Thread Shawn Milochik

I think that there is frustration on the part of the core dev team because 
people are (intentionally or not) demanding more and more of their time in the 
form of feature requests without understanding what the costs are and what 
resources exist.

There is frustration on the part of some Django users who would like to 
contribute but feel that anyone not in the core dev team is a third-class 
citizen with a tiny voice, and think that spending any time working on a ticket 
is slightly less likely to be worthwhile than writing an iPhone app and hoping 
Apple approves it for the App Store.

In my opinion, the problem lies not at either end, but in the middle. The way 
Trac is currently being used allows anyone at all to give tickets a status that 
the individual may not actually have the understanding to judge. To compensate 
for this, the core developers are each forced to rely on one another and their 
own small circle of lieutenants (as Linus does) to know whose code to actually 
take the time to evaluate. 

Ideally, people who want to contribute to Django should be able to adopt any 
open ticket in the bug tracker, work on it (with any necessary communication 
with this list), and see their work accepted if it's done well. At present this 
is not the case.

A potential solution is to treat bug tracker permissions a bit more like the 
"commit bit," where accepting bugs would be limited to people who understand 
both the process and the direction/vision of Django. This would cost time, but 
could alleviate the frustration on both sides and ultimately result in more 
work getting done, not least because more people would be encouraged to 
participate.

These are just my thoughts based mostly on the demoralizing thread Jacob is 
addressing with this one. I have also found it demoralizing, because it makes 
me feel like it's not worth aspiring to contribute to Django because there are 
too many obstacles. Some of Russell's comments do counter that sentiment, but 
it still seems like there is no way to have any confidence about what to work 
on without having the insight of a core developer. Again, this is all my 
opinion and I could be way off.

Shawn


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

Re: Process discussion: reboot

2010-04-19 Thread Peter Landry

On 4/19/10 10:19 AM, "Jacob Kaplan-Moss"  wrote:

> Hi folks --
> 
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
> 
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
> 
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
> 
> Jacob

One suggestion that jumped out at me (which I admittedly know very little
history about with regards to Django or other projects) was the "trunk
ready" branch(es) [1]. Perhaps an effort to outline what that process might
entail in detail, to determine if it would address any concerns?

For my part, I see that it could be helpful to let some patches/ideas get a
shot at integration without having to endure the (necessarily) more rigorous
core commit trails.

I'm not really comfortable suggesting any concrete plans for how that might
happen though. A single almost-trunk branch? A branch per
lieutenant/component? I'm wary of adding too much bureaucracy and overhead.
I think it's pretty clear that the core Django process is successful, and
this seems like a low impact (though potentially high effort?) way to
involve more of the community.

Peter

[1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b

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

Process discussion: reboot