On Tue, Dec 08, 2015 at 06:57:42PM -0500, Martin Owens wrote:
On Tue, 2015-12-08 at 12:53 -0800, Bryce Harrington wrote:
Yep.
Do you have a branch you're working on? I'd like to pitch in as you go.
Yeah I can set one up.
Right now I'm mostly working out design details - what interfaces do we need, what data should they present, what should they link to, and so on. I'm capturing this thinking on the wiki here, and would welcome collaboration on this:
http://wiki.inkscape.org/wiki/index.php/FundedProjectSystemDevelopment
There are two near term goals I have in mind.
First is to enable people to sign up for the funded projects, which is the most important functionality we need in order to start using the system; the WorkerApplicationForm is high on the todo list for this goal. I suppose we could get by without the rest of the system if we at least had this piece functioning.
Second is to display a listing of project ideas for GSoC 2016, which kicks off in Feb. This can be done with a subset of the overall functionality, and it's a pretty core subset, so I think this is a useful objective (plus gives me a tight deadline). The data that this needs pretty much overlaps what we need for the general funded project system, but there might be a few GSoC-specific items (like mentor name(s)).
Rather than shoehorn that into the Project object, I'm thinking of splitting out a separate object, and allow Projects to have multiple of these objects. If a project is listed for GSoC 2016, 2017, and 2018 we could have three different sets of mentors. And potentially there could be per-GSoC year state info, such as it was attempted in 2016 but failed, in 2017 the applicants weren't accepted, and in 2018 it was accepted and completed successfully.
We could also have objects for the regular funded efforts too. I could imagine for a given project there could potentially be several failed efforts before someone completes it successfully. We have different kinds of data to track for regular funded efforts vs. GSoC, so maybe we one class for the GSoC data and another for the other both subclasses of an abstract Job class. And a Project could own an arbitrary number of objects of either class.
But here's my question... while this is a typical OOP architecture it exceeds my limited Django-fu, so I'm uncertain whether this is feasible to model in Django or is going to make things too complicated. What do you think?
Bryce