Low-Hanging Fruit

[Shawn Milochik]

This is partially inspired by the thread that won't die: "High Level Discussion about the Future of Django."

I want to contribute something back to Django. Specifically, I've already paid for my hotel and flights for DjangoCon 2010 and I'm definitely going to stay for the sprints. However, since I've only worked with Django and never on Django, I'd like to have some level of familiarity before then. Preferably, I'd like to handle a few tickets, both familiarizing myself with the process and getting in-depth knowledge of the small slices of Django's internals required to do so. Otherwise I probably won't be much use at the sprints.

Since looking at a ticket in Trac doesn't indicate whether it passes the filters mentioned in Russell's talk (i.e. not good for Django's design, wrong direction) and I haven't been part of the Django community long enough to know intuitively, I'd just like a little head start on being able to contribute something of value to Django.

So, I'm asking for anyone in the core (or close to it) to specifically point out any low-hanging fruit. This may seem on the face of it to be asking for others to waste time they could be spending supporting proven, trusted Django contributors. However, I think it's not, because I'm asking someone who already knows what's coming up in the queue to take a minute or two to say, off of the top of their head, "These specific tickets are worth working on." In the long run, this will actually benefit the core because (at least) one more developer will be contributing to Django.

Given the current state of the work on 1.2, this can easily wait for 1.2 to be released.

Thanks,
Shawn

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

[Karen Tracey]

On Mon, Apr 19, 2010 at 10:26 AM, Shawn Milochik <sh...@milochik.com> wrote:

So, I'm asking for anyone in the core (or close to it) to specifically point out any low-hanging fruit.

Off the top of my head, a ticket I saw some activity on recently but have not had time to look into making a test/fix for:

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

Admin raises an exception if the repr of an object that is modified/deleted is greater than 200 characters. Fix is probably to truncate the object's repr to the max length of the field it's being put in. (Note this error will only happen for DBs that actually enforce max_length -- sqlite, for example, will happily let you store >200 chars in a field declared to only hold a max of 200. So the test for this will only fail on current code for certain DBs.) First place I'd likely look to put a test for this would be regressiontests/admin_views.

Karen

[Shawn Milochik]

Karen,

Thanks very much. I appreciate the response.

I'll have a look into this (not to discourage anyone else from trying to beat me to it), and post to this list if I can shed light on this issue.

Shawn

[Russell Keith-Magee]

On Mon, Apr 19, 2010 at 10:26 PM, Shawn Milochik <sh...@milochik.com> wrote:
>
> So, I'm asking for anyone in the core (or close to it) to specifically point out any low-hanging fruit. This may seem on the face of it to be asking for others to waste time they could be spending supporting proven, trusted Django contributors. However, I think it's not, because I'm asking someone who already knows what's coming up in the queue to take a minute or two to say, off of the top of their head, "These specific tickets are worth working on." In the long run, this will actually benefit the core because (at least) one more developer will be contributing to Django.

If making it easier to identify low-hanging fruit will help more
people get involved, I don't see it as waste of time at all.

> Given the current state of the work on 1.2, this can easily wait for 1.2 to be released.

Compiling a list of specific tickets will take a while; I'll put this
on my todo list for post 1.2.

However, if you're looking for something to work on right now, I would
suggest three approaches.

Firstly, take a poke through the current Milestone 1.3 list [1]. Not
all these issues are guaranteed to be simple, but they have been
accepted and been given a mild prioritization. Ignore anything that is
Design Decision Needed or appears to be a feature request -- low
hanging fruit will almost always be simple bugs.

Secondly, pick an area in which you have some interest (say,
serialization [2] or testing [3]), and search trac for accepted
tickets tagged against that component. Look at the newest issues first
- they're the ones most likely to be simple problems with simple
fixes. Older bugs may also be simple, but there's also a chance that
old ticket == hideously difficult ticket; it may not be obvious until
you're knee deep. As with the 1.3 tickets - avoid anything DDN or
feature related.

Lastly, pick anything to do with documentation. This isn't a coding
problem, obviously, but writing up a documentation patch to clarify
some issue will help you get to know Django's Sphinx markup
extensions, and it's good practice for when you submit a bigger ticket
that does requires documentation

Also - when you're looking for something to work on, remember that you
don't necessarily have to submit a complete fix to make a valuable
contribution. Turning a problem report into a test case that is
integrated with Django's test suite is often just as valuable as a fix
for the problem. The only additional guidance I would provide here is
that if your test involves models, try to re-use existing test models
instead of adding new models.

I hope that is enough to help you find something to chew on. :-)

Yours,
Russ Magee %-)

[1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=component&milestone=1.3&order=priority

[2] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Serialization&order=priority

[3] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Testing+framework&order=priority

[Shawn Milochik]

Thanks, this advice is incredibly helpful, and your response is encouraging.

Shawn

[Gabriel Hurley]

I just want to second this suggestion from Russell:

On Apr 19, 8:11 am, Russell Keith-Magee <freakboy3...@gmail.com>
wrote:

> Lastly, pick anything to do with documentation. This isn't a coding
> problem, obviously, but writing up a documentation patch to clarify
> some issue will help you get to know Django's Sphinx markup
> extensions, and it's good practice for when you submit a bigger ticket
> that does requires documentation

Even beyond that, taking on documentation tickets will take you into a
broad range of areas and have you digging into the codebase to figure
out what the correct documentation ought to be. It's a great way to
find out what you weren't aware that you didn't know. (that's kind of
like preparing for the unexpected...)

- Gabriel

[Don Guernsey]

How do I sign up to help? Is there an overall schematic for how django works?

[Dougal Matthews]

On 19 April 2010 22:20, Don Guernsey <don.gu...@gmail.com> wrote:

How do I sign up to help? Is there an overall schematic for how django works?

Overview of the process.

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

Signup for trac.

www.djangoproject.com/accounts/register/

[Russell Keith-Magee]

On Tue, Apr 20, 2010 at 5:20 AM, Don Guernsey <don.gu...@gmail.com> 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].

As for overall schematics - we don't really have any formal design
documentation; historically, we have relied on our extensive
regression test suite, the user-space documentation and the
readability of Python as a language to communicate the design message.

However, I can see how some high level design documentation could help
newcomers get started. If you want to take this on as a project, it
sounds like a good way to become familiar with Django's internals and
help others do the same.

[1] http://docs.djangoproject.com/en/dev/internals/contributing/

Yours
Russ Magee %-)

[Jeremy Dunck]

On Mon, Apr 19, 2010 at 7:52 PM, Russell Keith-Magee
<freakb...@gmail.com> wrote:
> On Tue, Apr 20, 2010 at 5:20 AM, Don Guernsey <don.gu...@gmail.com> 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.