Gsoc 18 Project | Collect build statistics

[Mojca Miklavec]

Dear Vishnu,

On 25 March 2018 at 11:29, Vishnu wrote:
> Hi Mojca,
>
> I have submitted a draft proposal through GSOC portal.
> Please go through it and do review and suggest changes.

I'll try to provide a bit more feedback later, but just some quick points.

1.) Stretch goals are not asking you for your career goals, but rather:

Let's assume that you finish your work 3 weeks earlier; what will you
do next? Assume that you start mentoring another student next year:
what's your vision about the project, what task should/could be
implemented after the GSOC, or during next GSOC? How do you envision
integration/interplay with other parts of MacPorts website?

2.) There is no mention about the technologies/languages/frameworks
planned for use. You should be more specific about how you plan to
implement stuff. My suggestion would be python (maybe django), but
there are also plenty of other technical decisions to be made.

3.) Log files are not going to cut it. You should draft/propose the
database schema to be used in the project. (You can provide graphs or
plain text or whatever, but something that demonstrates which objects
you would store, which properties and what would be the relations
between objects.)

4.) How and where would you deploy your work in development (before
it's finished and deployed on our server)?

5.) For the timeline: you mention, for example "coding to gather port
information". But the timeline doesn't say when the website could be
deployed (somewhere temporary) to actually display all that data. What
will you use for frontend?

6.) You have scheduled installation statistics for the end. This means
that you would hardly be able to have time to deplay anything, let
alone test and fix things. Things like links to trac tickets,
livechecks etc. are less important and can be added at any given time,
but you will want to start collecting real data from users early in
the coding period, even if display will still be suboptimal, so that
you get an impression of where things / design needs to be improved
etc. The existing statistics page has some issues and since none of us
is fluent in rails to fix those issues, the project never took off due
to some design issues (not that hard to fix, but nobody did that) and
lack of advertising. You should aim for deployment of some kind as
early as possible, and to have the most important features finished by
the second evaluation, so that you can get feedback and have
sufficient time for bugfixing, documuntation etc.

Mojca