Call for Channels work

[Andrew Godwin]

Hi everyone,

We finally have everything in place to pay people from the MOSS funds given to us by Mozilla for Channels (and more importantly we now have the money itself), so now I'd like to open the call for help.

We have a list of tasks that need doing in Channels, and the money to pay people for it, so we would, naturally, like to find people we can pay that money to. Cruicially, we are *pre-approving* people to work on projects with a daily (or similar) rate; we don't want people to complete something and then not get what they expected, have someone do a fixed quote and end up not being able to finish, or have two people go after the same task.

The list of things that needs doing is here: https://code.djangoproject.com/wiki/ChannelsTasks

If you'd like to work on one of these things, get in touch with me directly (and...@aeracode.org) to discuss the task and what's involved; once you're fully briefed and think you have a handle on the work, our separate Django MOSS committee will take over approval of the request. (I am not on that committee for conflict of interest reasons, but am trying to help out where I can with the process)

Like GSOC, we expect people applying to work on these tasks to have at least some track record of contributing to open source and working with Django or a similar project; we are unlikely to approve someone with no visible experience.

The most pressing issues are all test-related - specifically around building out a comprehensive test suite around Daphne and the workers, and getting load testing and similar trials done on the code so it can start to be honed for full release. If you're at all interested in this work, I strongly encourage you to get in touch.

If you have any questions, feel free to respond here or email me directly!

Andrew

[Tom Christie]

Do the Django MOSS committee have any plans for the request parsing/response rendering portion of the Django MOSS proposal?

I'm assuming that any of the following could be reasonable choices:

* Expecting to issue a call for work in due course, but treating channels as the priority for now.

* Defer any decisions on it until the channels portion is deemed sufficiently complete.

* Decide that it's no longer regarded as a priority and use the resource elsewhere.

* Decide that it would conflict with the REST framework MOSS grant and use the resource elsewhere.

Asking more from a stand-point of transparency, than trying to push for a 'call for work' to be issued.

Personally, the second option on that list probably sounds like the best overall choice at the moment, but I think any could be valid.

Cheers,

  Tom

[Jacob Kaplan-Moss]

Hi Tom -

This is a great question, and thanks for asking it. The short version is "we're not quite sure yet, and we need to work this bit out."

To go into more details, first I need to explain a bit about how the MOSS committee (of which I'm a part) works, and what it is and isn't doing. 

Specifically, I want to note that we're *not* making technical decisions. So when it comes to Channels work, Andrew is the "technical lead" (for want of a better term), so delegating decisions about what to do to him. Our job is to ensure that we're spending the MOSS money effectively, so what we do is:

- review proposals to make sure we believe the person is capable of completing the work they've proposed, and that the budget they're proposing is reasonable (this is very similar to how we might review a GSoC proposal, with the added wrinkle of reviewing financial quotes)

- review the completed work to double-check that the task is complete

- coordinate between people doing the work and the DSF to get invoices paid

You'll note that nowhere are we deciding things like "should this thing be built?" -- we're judging "can this person build the thing, and are they charging appropriately for their work?". This is a fairly deliberate choice, which mimics the way the DSF doesn't tell the core developer team what to build, but instead tries to spend its money in a way that helps the core team build what they want to build. 

So here's where things get sticky: what do we do about non-Channels work? As you note, the MOSS money was earmarked for more than just Channels. But, we don't have a mechanism to delegate the "what should we build" part of the question for work other than channels.

We need to work this part out, and I'll take ownership of finding an answer here. If you have any suggestions, I would really love to hear 'em. 

Jacob

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f1b3bf18-b8dd-49c9-8b34-9125a2ff9d6e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tom Christie]

> we don't have a mechanism to delegate the "what should we build" part of the question for work other than channels.

I guess there's two aspects to that.

1. Do Mozilla allow some flex in meeting the proposal / do we have an differing priorities now / do we want to discuss what those should be?

2. Breaking down request parsing/response rendering, as initially described in the proposal, into a call for work. (Assuming we do want to include it?)

Given the release timelines I don't think we're in any great rush to make decisions here - 1.11 isn't due til April '17.

Couple of options:

* Plan to make a firm decision at the core team meeting in Django Under the Hood, having solicited feedback more widely first?

* I could take on drafting up a call for work on the request/response portion. If there's a strong applicant for it, then we'd have plenty of time for it to start making its way in, without being remotely up against an alpha release deadline. (That way around would rather write me out of being an applicant, but might work well if we get the right person on board, and there might be scope for an a review/advisory role from Tim or myself)

No firm opinions at this point, myself.

  Tom

[Andrew Godwin]

On Tue, Jun 14, 2016 at 3:03 PM, Tom Christie <christ...@gmail.com> wrote:

> we don't have a mechanism to delegate the "what should we build" part of the question for work other than channels.

I guess there's two aspects to that.

1. Do Mozilla allow some flex in meeting the proposal / do we have an differing priorities now / do we want to discuss what those should be?

We're allowed some flex as long as it's roughly within the bounds, is my understanding; certainly I would say as long as we meet the terms of the proposal (implementing request/response improvements) we're good.

 

2. Breaking down request parsing/response rendering, as initially described in the proposal, into a call for work. (Assuming we do want to include it?)

Yes, we need to; I just don't have the bandwidth to manage the work calls for that as well as the Channels side.

 

Given the release timelines I don't think we're in any great rush to make decisions here - 1.11 isn't due til April '17.

Couple of options:

* Plan to make a firm decision at the core team meeting in Django Under the Hood, having solicited feedback more widely first?

* I could take on drafting up a call for work on the request/response portion. If there's a strong applicant for it, then we'd have plenty of time for it to start making its way in, without being remotely up against an alpha release deadline. (That way around would rather write me out of being an applicant, but might work well if we get the right person on board, and there might be scope for an a review/advisory role from Tim or myself)

No firm opinions at this point, myself.

I'd like us to get going on this earlier than November, but I can't offer much extra time towards it; if you can work on drafting a call that would be great. Why would this write you out of pitching for it, though?

Andrew 

[Tom Christie]

> if you can work on drafting a call that would be great

Sure, sounds like a sensible place to start.

I won't get onto anything immediately, but I'll start to have a think about spec'ing it out at some point.

(Other offers/progress on this from anyone also welcome in the meantime tho')

> Why would this write you out of pitching for it, though?

Yes, fair point.

  - Tom