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