Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[orokusaki]

I think I can play this:

Q: Why is so much valuable time wasted on insulting other people,
instead of making money?
A: "We are all born ignorant, but one must work hard to remain
stupid."

Q: Why do folks turn away constructive criticism with a sarcastic
snicker?
A: "None but the well-bred man know how to confess a fault, or
acknowledge himself in an error."

Finally:

Q: Why are there those who micro manage, those who play follow the
leader, and those who have a vacation home in Juno Beach FL, a boat, a
Jaguar XKR, 2-3 months of vacation per year, and a wife who is
quitting her job to spend time on helping endangered loggerhead sea
turtles, just because she can?
A: "All mankind is divided into three classes: those that are
immovable, those that are movable, and those that move."


Giving money to sign holders is never a good idea, but when I handed a
filthy bum a dollar fifty or so in change once without his
solicitation, and he threw it on the ground in prideful ignorance, I
realized then what separated him from me.



On Apr 19, 5:23 pm, Bitrot McGee  wrote:
> Q: When will Django finally have every feature I want?
> A: "Ambition has its disappointments to sour us, but never the good
> fortune to satisfy us."
>
> Q: What the fuck is taking so long?
> A: "As we enjoy great advantages from the inventions of others, we
> should be glad of an opportunity to serve others by any invention of
> ours; and this we should do freely and generously."
>
> Q: Should certain Trac fields only be editable by commiters?
> A: "Those who would give up Essential Liberty to purchase a little
> Temporary Safety, deserve neither Liberty  nor Safety."
>
> --
>
> I hope this attempt to lighten the mood isn't too distracting.
>
> To the core team: your efforts are so, so appreciated. Benjamin
> Franklin (et al.) know that you have a lot of other things you could
> be doing, and that working on Django is too often thankless. Thank
> you! You all deserve many, many IRL ponies. A herd of ponies.
>
> To everyone: I'd like to close with a quote by Richard Penn: "We must,
> indeed, all hang together, or assuredly we shall all be forced to use
> Rails separately." Please keep that in mind. It seems relevant for
> some reason.
>
> ~Bitrot
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> 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 django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[orokusaki]

Since you have a PhD in computer science and you're seven years older
than me, and you work for me, for free, while I have exactly zero
computer science credits (or anything related), I think "the
internets" award goes to you.


On Apr 19, 8:23 pm, Russell Keith-Magee 
wrote:
> On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee  wrote:
> > Q: When will Django finally have every feature I want?
> > A: "Ambition has its disappointments to sour us, but never the good
> > fortune to satisfy us."
>
> > Q: What the fuck is taking so long?
> > A: "As we enjoy great advantages from the inventions of others, we
> > should be glad of an opportunity to serve others by any invention of
> > ours; and this we should do freely and generously."
>
> > Q: Should certain Trac fields only be editable by commiters?
> > A: "Those who would give up Essential Liberty to purchase a little
> > Temporary Safety, deserve neither Liberty  nor Safety."
>
> > --
>
> > I hope this attempt to lighten the mood isn't too distracting.
>
> You, good Sir, win the internets. :-)
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> 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 django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[Jerome Leclanche]

On Tue, Apr 20, 2010 at 9:20 AM, orokusaki  wrote:
> Q: Why do folks turn away constructive criticism with a sarcastic
> snicker?
> A: "None but the well-bred man know how to confess a fault, or
> acknowledge himself in an error."

Careful there, some devs might tweet-call troll while you're not watching.
It's not like anyone warned them about the attitude ;)

J

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

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[Andrew Badr]

Umpires? Strike three off a curveball?

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

Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process

[Florian Apolloner]

On Apr 20, 10:38 am, Andrew Badr  wrote:
> Umpires? Strike three off a curveball?
+1, though I'd quoted big bang theory, no need for a umpire, bdfl
should be more than enough!

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[Jacob Kaplan-Moss]

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[Jacob Kaplan-Moss]

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[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 django-develop...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-developers+unsubscr...@googlegroups.com.
>>> 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 django-develop...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-developers+unsubscr...@googlegroups.com.
>> 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 django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> 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

Re: Low-Hanging Fruit

[Jeremy Dunck]

On Mon, Apr 19, 2010 at 7:52 PM, Russell Keith-Magee
 wrote:
> On Tue, Apr 20, 2010 at 5:20 AM, Don Guernsey  wrote:
>> How do I sign up to help? Is there an overall schematic for how django
>> works?
>
> There's no official signup process; just dig in and get your hands
> dirty. General guidance on how to get started can be found here [1].

For what it's worth, the homepage of Trac includes a "Getting Involved" section:
http://code.djangoproject.com/#Gettinginvolved
This includes a link to a wiki page with low-hanging fruit:
http://code.djangoproject.com/wiki/LittleEasyImprovements

It looks like that list isn't too actively maintained, but it might be useful.

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[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 django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com
> >> .
> >> 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 django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com
> > .
> > 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 

Running doc tests in Django's test suite

[Anssi Kaariainen]

I am trying to run some doc tests, but can't figure out how.
Specifically I would like to run the doc tests in regressiontests/
forms/widgets.py.

Running "./runtests.py --settings=test_sqlite forms" from the tests
directory it runs the unit tests (changing them results in failures)
but not the doc tests (no failures if changed). I have tried all kinds
of combinations like forms.widgets, forms.widgets_tests
forms.tests.widgets_tests as the last argument... but I just can't
figure out how to run them. So, could someone please help me?

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

Re: Running doc tests in Django's test suite

[Karen Tracey]

On Tue, Apr 20, 2010 at 3:44 PM, Anssi Kaariainen wrote:

> I am trying to run some doc tests, but can't figure out how.
> Specifically I would like to run the doc tests in regressiontests/
> forms/widgets.py.
>
> Running "./runtests.py --settings=test_sqlite forms" from the tests
> directory it runs the unit tests (changing them results in failures)
> but not the doc tests (no failures if changed). I have tried all kinds
> of combinations like forms.widgets, forms.widgets_tests
> forms.tests.widgets_tests as the last argument... but I just can't
> figure out how to run them. So, could someone please help me?
>
>
Oops. r12998 apparently broke the running of the forms doctests specified in
tests.py, that's why you cannot get the widget_tests doctest to run. I've
fixed this by reverting the r12998 change that caused this.

./runtests.py --settings=test_sqlite forms.widgets_tests

should now run the tests you are looking to run.

Karen

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

Re: Process discussion: reboot

[Robert Coup]

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

Re: Running doc tests in Django's test suite

[Alex Gaynor]

On Tue, Apr 20, 2010 at 4:54 PM, Karen Tracey  wrote:
> On Tue, Apr 20, 2010 at 3:44 PM, Anssi Kaariainen 
> wrote:
>>
>> I am trying to run some doc tests, but can't figure out how.
>> Specifically I would like to run the doc tests in regressiontests/
>> forms/widgets.py.
>>
>> Running "./runtests.py --settings=test_sqlite forms" from the tests
>> directory it runs the unit tests (changing them results in failures)
>> but not the doc tests (no failures if changed). I have tried all kinds
>> of combinations like forms.widgets, forms.widgets_tests
>> forms.tests.widgets_tests as the last argument... but I just can't
>> figure out how to run them. So, could someone please help me?
>>
>
> Oops. r12998 apparently broke the running of the forms doctests specified in
> tests.py, that's why you cannot get the widget_tests doctest to run. I've
> fixed this by reverting the r12998 change that caused this.
>
> ./runtests.py --settings=test_sqlite forms.widgets_tests
>
> should now run the tests you are looking to run.
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Karen,

Do you have any idea how that caused the fail, it should be completely
innocuous?

Alex

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

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

Re: Running doc tests in Django's test suite

[Karen Tracey]

On Tue, Apr 20, 2010 at 5:03 PM, Alex Gaynor  wrote:

>
> Do you have any idea how that caused the fail, it should be completely
> innocuous?
>
>
I'm guessing it's got something to do with the ... at the beginning of the
line making it appear to be a shell continuation line, not ellipsis for
output checking. But why that has the ultimate effect of causing none of the
doctests defined in the __test__ dictionary in forms/tests.py to run...I
dunno. But they don't run with that change.

Karen

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

Re: Running doc tests in Django's test suite

[Alex Gaynor]

On Tue, Apr 20, 2010 at 5:09 PM, Karen Tracey  wrote:
> On Tue, Apr 20, 2010 at 5:03 PM, Alex Gaynor  wrote:
>>
>> Do you have any idea how that caused the fail, it should be completely
>> innocuous?
>>
>
> I'm guessing it's got something to do with the ... at the beginning of the
> line making it appear to be a shell continuation line, not ellipsis for
> output checking. But why that has the ultimate effect of causing none of the
> doctests defined in the __test__ dictionary in forms/tests.py to run...I
> dunno. But they don't run with that change.
>
> Karen
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Ok, I'll throw a patch up to convert it to an equality comparison this
evening.  That'll be ellipsis safe and work on CPYthon and PyPy.

Alex

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

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

Re: Process discussion: reboot

[Jacob Kaplan-Moss]

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[Robert Coup]

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

Cujo .... an experimental branch of django.

[Kevin Howerton]

Cujo... for starters it's Amon Tobin's first moniker (he remixes jazz
into some delightful tunes, if you don't know of him I strongly
recommend you go to your local record store and pick up a copy of
"Adventures in Foam").

Also, I felt it was somewhat apt due to the rabid nature of the
discussions the past few days ... and I think there's a Stephen King
novel of the same name about a dog with rabies or something.

So we have a clever name ... someone needs to make a rabid, crazy-eyed
pony for the logo and I think we are pretty much done.

Also, if anyone wants to help with the code ... that would be good too.

Currently, my main two concerns are this ticket (
http://code.djangoproject.com/ticket/7539 ... which already has a
working patch I believe) ... and what I perceive is poor exception
handling in templates.

http://www.bitbucket.org/kevin.howerton/cujo/wiki/Home

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

Re: Process discussion: reboot

[Jacob Kaplan-Moss]

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[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 django-develop...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> django-developers+unsubscr...@googlegroups.com.
> >>> 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 django-develop...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> django-developers+unsubscr...@googlegroups.com.
> >> 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 django-develop...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-developers+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> 

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[Robert Coup]

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

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

Re: Process discussion: reboot

[Robert Coup]

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

Re: Cujo .... an experimental branch of django.

[Russell Keith-Magee]

On Wed, Apr 21, 2010 at 6:01 AM, Kevin Howerton
 wrote:
> Cujo... for starters it's Amon Tobin's first moniker (he remixes jazz
> into some delightful tunes, if you don't know of him I strongly
> recommend you go to your local record store and pick up a copy of
> "Adventures in Foam").
>
> Also, I felt it was somewhat apt due to the rabid nature of the
> discussions the past few days ... and I think there's a Stephen King
> novel of the same name about a dog with rabies or something.
>
> So we have a clever name ... someone needs to make a rabid, crazy-eyed
> pony for the logo and I think we are pretty much done.
>
> Also, if anyone wants to help with the code ... that would be good too.
>
> Currently, my main two concerns are this ticket (
> http://code.djangoproject.com/ticket/7539 ... which already has a
> working patch I believe) ... and what I perceive is poor exception
> handling in templates.
>
> http://www.bitbucket.org/kevin.howerton/cujo/wiki/Home

Hi Kevin,

Great to see someone taking up the challenge of curating a private
branch. Although you've described this as a "hostile" branch with no
intention of keeping backwards compatibility, I would like to point
out that I can't see any reasons the tickets you've identified can't
be resolved in a backwards compatible manner. If at all possible (and
if you're amenable), I'd like to see the work you do merge back into
trunk eventually.

Regarding some of the issues you've highlighted:

 * #7539 has a long history of discussion, but only recently has there
been a viable patch. At the time of feature discussion for 1.2, there
were still some big issues being sorted out (search django-dev
archives for details). I believe many of these issues have been
addressed in the most recent patches, but those were only provided in
Jan and Feb of this year, well after the feature freeze for 1.2.
Looking at the most recent patch, I notice that it doesn't contain any
documentation. I suspect there may also be some updates needed
following some recent changes to deletion behavior. However, this
could easily be something that gets integrated in the 1.3 timeframe if
somebody drives the issue.

 * #2259 has stalled mostly because nobody has been driving it. It's
certainly a problem, but there are clearly some issues that need to be
resolved. If #2259 is important to you and you want a fix in trunk,
those issues will need to be discussed and resolved on django-dev.
That said, having a working solution in a branch would be an easy way
to kickstart that discussion.

 * As for exception handling in templates - you won't get any argument
from me that error handling is an area that Django could do better.
Suggestions and patches welcome.

I would also point out that #7539 and #2259 are quite separate issues.
If you're doing this work with an eye to delivering work back to
trunk, keep in mind that we will need a clean patch that contains
*only* the #7539 fixes (or the #2259 fixes) and nothing else. This
probably means that you'll need to maintain feature branches internal
to your own branch. You may well have a master repository that
contains a merge of all your subbranches, but the independent
feature-specific branches will be a critical part of managing any
feedback to trunk.

Best of luck with your branch - once 1.2 is out the door and you have
something you'd like to push back to trunk, let us know.

Yours,
Russ Magee %-)

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

Re: Process discussion: reboot

[VernonCole]

Thanks for the advice. Trying to make a contribution is why I'm here.
That's why I worry about version control systems.  Last time I tried
to contribute to an open source project via a "semi-official
mirror" (this one actually run by a core developer) it did not work
and I ended up having to resubmit the work to CVS. I now have commit
permission on that project (pywin32) so it's no longer a problem.
Jacob seemed to be suggesting a single dvcs ("THE branch") so I
thought I would weigh in on the choice. Sorry I missed the discussion
two years ago.

   Meanwhile, I suppose I must stick with svn if I expect to have my
work accepted, because my contribution will very likely be
controversial, and I prefer to only fight one battle at a time.  On
the other hand, getting some test time in a less critical environment
would be a really good thing, and would increase the chances of my
work having a good examination by other developers.
  Umm -- time to explain:

  I am the principle maintainer of adodbapi on sourceforge. I have
spent the last little while making adodbapi django compatible.  (The
new version allows the programmer to change 'paramstyle' at run time.)
The existing MS-SQL back end for django is a fork taken from the
adodbapi project *before* it was changed to be ready for Python 3 and/
or IronPython.  The alpha-test version now running will operate in all
three environments -- and should be a real aide to both the IronPython
and Python 3 django integration projects which are now under way.  It
should be a fairly minor change to the existing MS-SQL back end to use
the (new) trunk version of adodbapi rather than the fork.

  That's not controversial -- here comes the controversy:

  There is finally a solid release of IronPython 2.n available for
Linux. (Ubuntu Lucid).  The existing adodbapi will not work there, due
to lack of a COM interface.  I now have to put in genuine .NET calls
to reach the database.  I started working on that project yesterday.
When I am done the result will be that django on IronPython (or Python
3?) will be able to use *only*  MS-SQL or SQLite databases. Not a
pretty picture. In order to access other database engines, the engine
specific code for all of the other database engines will have to be
modified to fall back to ADO when their native adapters are not
present.  That's a lot of fixing of things that are not broken.  I
think the final result will be a version of django which is a lot more
flexible, but it's gonna be a hard sell.
--
Vernon

On Apr 19, 8:05 pm, "Sean O'Connor"  wrote:
> 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'Connorhttp://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"