Process discussion: reboot

[Jacob Kaplan-Moss]

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

[Peter Landry]

On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> 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

[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

[Tom Evans]

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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 10:19 AM, orokusaki <flashde...@gmail.com> 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

[David Zhou]

On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 10:19 AM, orokusaki <flashde...@gmail.com> 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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry <pla...@provplan.org> 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

[orokusaki]

Yes, thank you David.

On Apr 19, 9:38 am, David Zhou <da...@nodnod.net> wrote:
> On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

[Peter Landry]

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

[Dennis Kaarsemaker]

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!

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 11:05 AM, Dennis Kaarsemaker
<den...@kaarsemaker.net> 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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 10:38 AM, David Zhou <da...@nodnod.net> 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

[David Zhou]

On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 10:38 AM, David Zhou <da...@nodnod.net> 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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 12:09 PM, orokusaki <flashde...@gmail.com> 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

[James Bennett]

On Mon, Apr 19, 2010 at 12:09 PM, orokusaki <flashde...@gmail.com> 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."

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 12:24 PM, orokusaki <flashde...@gmail.com> 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 Kaplan-Moss]

On Mon, Apr 19, 2010 at 12:23 PM, orokusaki <flashde...@gmail.com> 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

[Giuseppe Ciotta]

On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss <ja...@jacobian.org> 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.

[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

[Mike]

On Apr 19, 10:19 am, Jacob Kaplan-Moss <ja...@jacobian.org> 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
trunk@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.81 99 0.66 96.40 telenieko
14. 68 0.82 96.63 94 0.63 97.02 ikelly
15. 67 0.81 97.43 79 0.53 97.55 jkocherhans
16. 44 0.53 97.96 75 0.50 98.05 wilson
17. 39 0.47 98.43 78 0.52 98.57 zgoda
18. 34 0.41 98.84 64 0.43 99.00 mboersma
19. 32 0.39 99.23 60 0.40 99.40 tekNico
20. 25 0.30 99.53 25 0.17 99.57 simon
21. 14 0.17 99.70 24 0.16 99.73 toxik
22. 11 0.13 99.83 18 0.12 99.85 ramiro
23. 8 0.10 99.93 15 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

[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.""

[Don Guernsey]

Once I understand what I am doing I would have no problem putting together an "ebb and flow" diagram with pointers to code....something 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).

[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

[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 <den...@kaarsemaker.net>
wrote:

> On ma, 2010-04-19 at 15:47 +0000, Peter Landry wrote:
>
>
>
>
>
> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" <ja...@jacobian.org> wrote:
>

[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

[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.

[Peter Baumgartner]

On Mon, Apr 19, 2010 at 8:19 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 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

[Alex Gaynor]

On Tue, Apr 20, 2010 at 11:39 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta <gci...@gmail.com> 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-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>

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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta <gci...@gmail.com> 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

[Jacob Kaplan-Moss]

On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley <gab...@gmail.com> 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.

[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.

--
Stephen Crosby
Web Developer
lithostech.com

[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.

[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 <bmhei...@gmail.com> 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.
>

> >> django-develop...@googlegroups.com<django-developers%2Bunsu...@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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > django-develop...@googlegroups.com<django-developers%2Bunsu...@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-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

[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/

[Alex Gaynor]

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
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Robert Coup]

Hi all,

On Tue, Apr 20, 2010 at 8:34 AM, Gabriel Hurley <gab...@gmail.com> 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 :)

[Jacob Kaplan-Moss]

On Tue, Apr 20, 2010 at 3:53 PM, Robert Coup
<rober...@onetrackmind.co.nz> 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

[Brandon H]

+1

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

[Jeremy Dunck]

On Mon, Apr 19, 2010 at 9:19 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 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?

[Robert Coup]

On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 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 :)

[Jacob Kaplan-Moss]

On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup
<rober...@onetrackmind.co.nz> 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

[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 <robert.c...@onetrackmind.co.nz>
wrote:

> On Wed, Apr 21, 2010 at 9:12 AM, Jacob Kaplan-Moss <ja...@jacobian.org> 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

[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 <alex.gay...@gmail.com> wrote:

> On Tue, Apr 20, 2010 at 1:36 PM, Bmheight <bmhei...@gmail.com> 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 <stevecr...@gmail.com>

> For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

[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

[SmileyChris]

On Apr 21, 9:46 am, Jeremy Dunck <jdu...@gmail.com> 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.

[Robert Coup]

On Wed, Apr 21, 2010 at 10:00 AM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Tue, Apr 20, 2010 at 4:49 PM, Robert Coup
> <rober...@onetrackmind.co.nz> 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 :)

[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 <smileych...@gmail.com> 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.

[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

[Robert Coup]

On Wed, Apr 21, 2010 at 10:18 AM, SmileyChris <smile...@gmail.com> 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 :)

[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" <sean.b.ocon...@gmail.com> 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 <adys...@gmail.com> 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
>

> > django-develop...@googlegroups.com<django-developers%2Bunsu...@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-d...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > django-develop...@googlegroups.com<django-developers%2Bunsu...@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-d...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > django-develop...@googlegroups.com<django-developers%2Bunsu...@googlegroups.com>
> > .

[Giuseppe Ciotta]

On Tue, Apr 20, 2010 at 4:39 PM, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta <gci...@gmail.com> 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.

My personal opinion is that the community should continue using the
fields we have now, because they ease the ticket evaluation job of
core developers.

I don't think adding additional fields will add burden for two reasons:
- this information is going to be easily shared between developers
- developer can have a better understanding of the whole situation,
because they can trust these field.

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

This would be super cool... really. But still, for reporting, "core
devs" fields look better to me. Having both fields and "featured
comments" would be perfect.

As I side note, I've switched from Trac to Redmine for my current
project, and it is *so* much easier to administer, there's *so* less
noise in tickets, and out of the box isn't a PITA as Trac is. I'm
extremely happy with it and I highly suggest to have a look at it
(it's ruby though, so we may be a little bit limited in terms of
hacking on it).

[Gustavo Narea]

Hello,

I'm glad someone from the core development team brings this up.

I've lost motivation to contribute to Django after the many failed
attempts to improve WSGI support. I consider myself of the users Shawn
Milochik describes: "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 ".

I am involved in many other Free Software projects and I can tell you
Django is the least contributor-friendly out of them. I can understand
that implementing feature requests is not something exciting if you
contribute in your spare time and you're not particularly interested
in that feature, but leaving potential contributors behind is
something I wouldn't understand.

My two cents,

- Gustavo.

On Apr 19, 3:19 pm, Jacob Kaplan-Moss <ja...@jacobian.org> 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

[Thomas Guettler]

The plan to make 1.3 a feature light release with focus on
fixing old bugs and tickets, was a good one.

I have some tickets in trac which are quite old, too. But it has been
a very long time, since I reviewed tickets of other people, too.

Sometimes I think the development process is slow. But that's wrong.
The development is just in parts I don't need up to now (for example multi db support).

Thomas

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
>

--

Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

[Adam Nelson]

After reading through this entire thread it seems that there are a few
points to be consolidated:

1. DVCS concerns should be pushed to 1.4+ and in the meantime, mirrors
are fine.
2. The management of the current Trac system has organizational issues
- i.e. many people don't know who committers are and whether they
should aggressively manage tickets since they have alot of power.
Nonetheless, these are manageable for now.
3. Version 1.3 should be feature-light

I would propose the following:

1. Finish version 1.2
2. Assign all of these tickets to 1.3 and nothing else:

http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=&has_patch=1&order=priority

These all have a patch and no milestone.

3. Go through all of the newly assigned 'milestone 1.3' tickets and
either close them as wontfix, apply the patch, or move them to a new
milestone called 'Next Major Release'.
4. Release version 1.3
5. Evaluate other stuff like major DVCS changes, Trac changes, etc...

I think this would be the best timeline for the community and is the
best way to maintain a good relationship with the people who have had
patches waiting for over a year. Marking them as wontfix is fine, as
long as some movement is made.

Cheers,
Adam

On Apr 22, 2:37 am, Thomas Guettler <h...@tbz-pariv.de> wrote:
> The plan to make 1.3 a feature light release with focus on
> fixing old bugs and tickets, was a good one.
>
> I have some tickets in trac which are quite old, too. But it has been
> a very long time, since I reviewed tickets of other people, too.
>
> Sometimes I think the development process is slow. But that's wrong.
> The development is just in parts I don't need up to now (for example multi db support).
>
>   Thomas
>
>
>
>
>
> 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
>
> --

> Thomas Guettler,http://www.thomas-guettler.de/

[Gabriel Hurley]

On Apr 22, 1:21 pm, Adam Nelson <a...@varud.com> wrote:

> 2. Assign all of these tickets to 1.3 and nothing else:
>

> http://code.djangoproject.com/query?status=new&status=assigned&status...

Awwww, only 900 tickets to work through for 1.3? Don't go too easy on
the core team! ;-)

All the best,
- Gabriel

[Jeremy Dunck]

On Thu, Apr 22, 2010 at 3:26 PM, Gabriel Hurley <gab...@gmail.com> wrote:
> On Apr 22, 1:21 pm, Adam Nelson <a...@varud.com> wrote:
>
>> 2. Assign all of these tickets to 1.3 and nothing else:
>>
>> http://code.djangoproject.com/query?status=new&status=assigned&status...
>
> Awwww, only 900 tickets to work through for 1.3? Don't go too easy on
> the core team! ;-)

To be clear, this is why the triage process exists. We need more
people to look at tickets, review them for the standards that Django
has set (good code, test coverage, documentation for any new features)
and mark them "ready for checkin".

The subset of tickets that achieve "ready for checkin" then take a
commiter's time for final review and merge.

[Adam Nelson]

I guess I'll jump in and start triaging. What about a ticket like
this:

http://code.djangoproject.com/ticket/2284

Super-ambiguous. There are dozens of tickets like this that are
frozen in time with no way for anybody to know what's going on. Maybe
there just needs to be a better way to handle this type of ticket?

Regards,
Adam

[Jeremy Dunck]

On Thu, Apr 22, 2010 at 4:36 PM, Adam Nelson <ad...@varud.com> wrote:
> I guess I'll jump in and start triaging.  What about a ticket like
> this:
>
> http://code.djangoproject.com/ticket/2284
>
> Super-ambiguous.  There are dozens of tickets like this that are
> frozen in time with no way for anybody to know what's going on.  Maybe
> there just needs to be a better way to handle this type of ticket?
>

First, thanks for taking the time to look with triaging in mind.

There may be dozens of tickets like this, but that's a small portion
of 900. :-)

In any case, yes, very old tickets may be inadvertently fixed or left
open, or they may still be accurate, but have bad patches on them.

In this specific case, I think the current status is captured in
comments 11 through 14 -- that the logic for executing initial SQL
breaks in cases where extended SQL syntax (such as pgsql's DECLARE)
includes quoted text, etc.

You can see the Malcolm objected to the latest patch in 11, and
ScottAnderson objected to it in 13.

Certainly, the patch needs improvement because it doesn't include any
test cases. Possibly, the patch as-is isn't good for the reasons
Malcolm listed, but it's hard for me to tell without doing my own
testing. I'd mark patch-needs-improvement. If you're feeling more
ambitious, I'd suggest coming up with a set of initial SQL files that
exercise the assumptions of the loading code.

If it's helpful, I like this summary of unit testing points:
http://media.pragprog.com/titles/utj/StandaloneSummary.pdf