Google's Summer of Code 2019

Django is a mentor organization for the 2019 Google Summer of Code. Read ​​https://summerofcode.withgoogle.com Google's page] for more information on how the program works.

Django's GSoC program is being coordinated by the current Django Fellows, Carlton Gibson and Mariusz Felisiak.

Mentors

If you're interested in mentoring -- supervising a student in work on Django-related activities -- add your name, email, and the sort of projects you're interested in mentoring here:

Carlton Gibson (carlton.gibson@…) - Anything, most likely.

Students

Student application period opens March 25, 2019 and ends April 9, 2019.

If you'd like to get started on your proposal early, we'll be looking for a few things.

• You'll need to have a concrete task in mind (some ideas are below) along with a solid idea of what will constitute "success" (you tell us).
• If your proposal is a single large feature, library or site, you'll need to present a detailed design specification. This proposal should be posted to ​ ​django-developers, where it can be refined until it is accepted by the developer community.
• We'll want to know a bit about you -- links to previous work are great, if any. If you're proposing something ambitious, you'll need to convince us that you're up to the task.
• You'll also need to provide us with a schedule, including a detailed work breakdown and major milestones so your mentor can know if and when to nag you :)

Here's an example of an accepted proposal from a previous year:

​* ​https://gist.github.com/chrismedrela/82cbda8d2a78a280a129

Note that none of the ideas below are good enough to be submissions in their own right (so don't copy and paste)! We'll want to know not just what you want to do but how you plan to pull it off.

Don't feel limited to the ideas below -- if you've got a cool project you want to work on, we'll probably be able to find you a mentor. We plan on approving as many projects as we possibly can.

We're accepting any GSOC proposal that fits one of the following three categories:

• Work on Django itself - such as the ORM, forms, etc. This is what we've traditionally accepted GSoC entries in.
• Work on tools to support Django - the dashboard (​​https://dashboard.djangoproject.com/) is a good example of an existing tool that would have fit into this category.
• Work on libraries that supplement or add new features to Django to ease development - South and Django Debug Toolbar are good examples of existing projects that would have fit here.

We're not looking for people to work on existing third-party libraries - we aren't able to guarantee commit access to them. We may allow an exception if a maintainer of the library in question agrees to help mentor beforehand.

The broadening in scope is to allow people to work on new ideas to help Django development and developers without tying you down to having to implement it in the core codebase (and thus ruling out some projects that might otherwise be useful).

We're still going to be strict with what we accept - you'll need to provide a strong use case for your idea and show that it would be useful to a majority of developers or significantly improve the development of Django itself.

We're not looking for small groups of incremental updates - like "improve Django's Trac" - nor are we looking for impossible tasks, like "replace Trac with this brand new issue tracker I'm writing". What you propose should be a single project, achievable within the time period of GSoC, and something the core developers can help mentor you on.

We're also not looking for sites or projects that are merely written in Django - this GSoC is not for you to propose your new forum hosting site or amazing Django-based blogging engine.

Note that when you contribute code, you will be expected to adhere to the same contribution guidelines as any other code contributor. This means you will be expected to provide extensive tests and documentation for any feature you add, you will be expected to participate in discussion on ​​django-developers when your topic of interest is raised. If you're not already familiar with ​​Django's contribution guidelines, now would be a good time to read them - even if you're not applying to work on Django core directly, we'll still want the same level of contribution.

How can I improve my chances of being accepted?

The best thing you can do to improve your chances to be accepted as a Django GSoC student is to start contributing now. Read up on ​Django’s contribution documentation and make yourself known to the core team by your contributions (ideally, related to the area of your proposal). That way, when it comes time to evaluate student applications, you’ll be a known individual and more likely to be able to get the attention you need to develop a proposal.

Communication

All GSOC-related communication is handled via the ​​django-developers mailing list. Any proposals for GSOC should be submitted there, as well as discussion on the proposed projects and any updates that students post.

Please be careful to keep content to the list clear and purposeful; if you have an idea, update, or criticism, please make sure you describe it in detail; it can be tedious asking people to clarify any vague statements.

Ideas

Here are some suggestions for projects students may want to propose (please feel free add to this list!). This isn't by any means the be-all and end-all of ideas; please feel free to submit proposals for things not on this list. Remember, we'd much prefer that you posted a draft proposal and your rough timeline / success conditions to the ​​django-developers list, even if it's already on the list below; it will help you get feedback on choosing the right part of a problem, as well as helping to see if there is any interest before you start drafting a full proposal.

When developing your proposal, try to scope ideas/proposals to the 4-month timeline -- simply proposing to fix a ticket or two will probably result in your proposal being rejected in favor of a more ambitious one. The GSoC does not cover activities other than coding, so certain ideas ("Write a more detailed tutorial" or "Create demonstration screencasts") are not suitable for inclusion here.

On the other side, though, be sure to be concrete in your proposal. We'll want to know what your goals are, and how you plan to accomplish them.

In no particular order:

Add Cross-DB JSONField (etc)

• Complexity: Medium

Task is to bring the fields from contrib.postrges into core. In particular JSONField. All supported DBs now have native JSON handling. There are versions for all DBs except SQLite already available to use as base examples.

First step is a POC field for SQLite. Then creating a unified field, with multiple backend. Finally determining a migration path from contrib.postgres.

JSONField is the obvious main target here, but ArrayField and even a suitably named version of HStoreField would be desirable too.

Improve Admin Filters

• Complexity: Medium

A number of the accepted issues on `contrib.admin` pertain to the filtering system.

They cover such topics as improving search, adding autocomplete to M2M list filters, and so on.

A project to combine and address a number of these tickets would be worthwhile.

Replace Form Media Class

• Complexity: Hard

Quoting Loic on the ticket: "My biggest issue with it is that it's a very naive approach to a complicated problem. It doesn't really fit with today's development practices where a project can easily grow to hundreds of static assets, where javascript offers concepts like AMD, where CSS gained preprocessors like LESS or SASS and where files are concatenated for performance.

Having each input widget pull its own assets can also be a performance footgun, and IMO it's hardy something we should recommend."

You will need to come up with a design here. There are a variety of third-party libraries from which you might glean best practices however the frontend tech world is currently in a state of reinvention so it might be hard to develop a suitable API that's suitable now but not in the future.

Test framework cleanup

• Complexity: Low

Django has an extensive test framework for Python code, a suite of tools to make server-side testing easier, and a project policy that no new code is added without tests. This has been a significant contributor to the stability of Django as a project.

However, this now means that Django has a very large and powerful test suite without much separation or control from a user's perspective, so the goal of this project would be to add new options and suite types to allow running of specific types of tests, be they only a certain class (e.g. unit-tests only, selenium tests only) or excluding tests (such as the ones in contrib or third-party apps) from the main test run easily.

Django's test suite is also very large with over 1000 models. In some areas, the tests are poorly structured and it is not clear where similar related tests should be placed. It is likely there may be some duplication of features tested, and there are certainly edge cases which are not tested. For example, standardising all the unit tests necessary for a particular model field type would be beneficial.

Issues to consider:

• How would users declare which tests they want to run?
• Which tests should be enabled by default, and how hard should this be to change?
• How will it be app maintainers run their tests?
• Should there be additional hooks to, for example, allow tests to be run against different database backends in sequence?
• Are there tools similar to the new --debug-sql option which would help developers working on Django?

See also:

• #13873 (more of a symptom of this problem)
• Part of this task could be auditing ​Django's coverage report and adding missing tests and removing dead code.

Improving the less popular database backends

• Complexity: Medium

Django supports several database backends, but not equally. The less popular backends -- Oracle in core, as well as open-source backends outside core, could probably use some love. As an example, Oracle has some problems:

The handling of case in database object names is problematic (e.g. #20487) Add more issues? While these alone would not fill an agenda for a full GSoC project, an interested student could collect enough related issues -- perhaps in more than one backend -- to keep busy for the whole term.

Keep in mind that for working on 3rd-party backends, a committer for the relevant backend will probably need to be involved in mentoring; however, given such involvement, Django will accept such GSoC projects.

See also:

• Trac's list of Oracle issues
• Similar queries for 3rd-party backends should be added here

Formset improvements

• Complexity: Low

One of the big problems in web programming is making a request object available everywhere that it might be needed. Some frameworks tackle this problem by using a threadlocal. A threadlocal is essentially a global variable that allows you to access stateful information, such as the currently active request.

Django takes a more structured approach, and encourages you to use function arguments and class attributes to pass around stateful information. This requires more discipline on the developer, but ultimately leads to more robust, less error-prone code that is easier to test.

The counterargument to Django's approach is that passing the request around everywhere that it might be needed is difficult. Formsets are one example given in support of this - Django's formsets are a classic example where you might want to pass a request down to an internal form - but this is surprisingly difficult to do with Django's FormSet infrastructure.

The problem isn't just about requests, either - there's a general problem in Django's FormSet and ModelFormSet objects that makes it difficult to pass in arguments to the Forms that are on them, or otherwise control the save process. This could be a request, the user that is making a particular change, or some other "ownership" related information.

While it is *possible* to work around this problem, it *should* be a well documented, easy to use capability.