2008/6/13 Edgars Jēkabsons <[EMAIL PROTECTED]>:
>
> On 11 Jūn., 03:45, "Russell Keith-Magee" <[EMAIL PROTECTED]>
> wrote:
>> On Wed, Jun 11, 2008 at 6:46 AM, Edgars Jēkabsons
>>
>> <[EMAIL PROTECTED]> wrote:
>> This is a triage process - we're not asking you to make decisions for
>> the community - we're asking you to filter the fire hose of tickets
>> and give us a trickle we can manage.
>
> Well, the contributing information contains the following text as exit
> for design decision needed marked tickets - "The community and/or core
> developers decide whether this ticket can and will be fixed". Seeing
> that there are >200 tickets waiting for "the community and/or core
> developers" to decide surely I'd like to help.

Yes, there are a lot of 'design decision required' tickets.

Some of the DDR tickets are mistakes of triage. For example, #2616 has
been commented on by both Jacob and Malcolm as a good idea in the
comments of the ticket - its reasonable to call this one 'Accepted'.
#7259 is really a bug report, with a patch. Generally, a bug doesn't
require a design decision - it should be fixed.

Some of the tickets are just stale. For example, any ticket referring
to problems with oldforms-admin needs to be revisited at this point;
either the problem still exists with newforms-admin, or the ticket
needs to be closed.

Even if you ignore these sorts of problems, there will still be a lot
of tickets requiring decisions. This isn't an inherently bad thing -
it just means that there are a lot of ideas for improving Django.

The best way to help isn't to make the decision yourself. When a
ticket is "accepted", we are essentially inviting people to commit
effort to fixing the problem or implementing the feature. We _really_
want to avoid giving someone the green light, then turning around and
telling them that their effort was wasted.

However, there is still a lot you can do by helping the core
developers to make decisions. Making 100 decisions is hard; making 1
decision (or even 10 decisions) is much easier. It's even easier if
you can provide a summary of the decision that needs to be made, the
various arguments for/against, etc. Find 10 "important" issues (by
whatever criteria you deem significant), summarize those tickets, and
bring them to the developers list for a decision.

That said, you also need to pay attention to timing. Given that we're
moving into a v1.0 release cycle, you're not going to get much
traction asking for design decisions about new features. You probably
will get some responses to design decisions about bugs. Once v1.0 is
out the door, we'll be looking for new features to add - if you're on
top of the ticket database, you'll be in a good position to make
recommendations.

>> It also calls for volunteers. These tickets don't fix themselves, and
>> you don't need a formal invitation or sprint to give you permission to
>> work on them. The Django contribution guide [1] contains more details,
>> but there is lots you could do to help out:
>>
>>  [1]http://www.djangoproject.com/documentation/contributing/
>
> Ironically http://code.djangoproject.com/ticket/6320 that improves the
> contributing information is marked as design decision needed with no
> progress for 5 months.

A good example of bringing up a ticket at the right time :-)

> Am I allowed to mark it as ready for checkin?

In this case, I'd say yes - the documentation improvements aren't
perfect, but they're a good first draft, and they reflect a discussion
that has been referenced on the ticket. In essence, a decusion _has_
been made - the ticket just hasn't been updated by a core developer.
Feel free to modify the state of any ticket where you can back up the
decision with a reference a django-dev descussion.

Documentation tickets are a bit of a wierd case, though. Whereas code
needs to be 100% correct, a good first draft of documentation is often
good enough. Whichever core developer commits a documentation change
will usually make a few edits of whatever text is provided, and then
Adrian will apply his journalistic talent and rewrite the whole thing
- making it much better in the process :-)

Yours,
Russ Magee %-)

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

Reply via email to