+1 with Matthias.

As an FYI, Krishna was a GSoC student in 2017 for SystemML. His project
went well and the community liked the quality of his work and his
dedication. Seeing this, after GSoC, he was given the opportunity to become
a committer, which he accepted.

I would definitely agree with Krishna - start early.

Here are my $0.02 to get started:
(Even though some of this is obvious, I am putting it here for posterity):

0a. Clone the project and build it locally. Figure out what you need to
learn (Maven, java, python, git, github or anything else) and might be
missing by searching through the readme files, mailing list archives and
JIRA sites.
0b. Try running a simple DML program; figure out what the simplest DML
program is. Try running the test suite - a small version of it - on your
local machine.
1. Try submitting a minor or simple pull request (PR). Get familiar with
git and github. There is a likelihood that you will mess up on your local
git and will need help to fix your problems.
2. Get familiar with members of the community. Find out who can help with
what parts of the code. This can be found out by going through the prior
list of commits/PRs, discussion on the mailing lists and JIRAs.
3. Be active in the community, send your questions in the mailing list;
interact with your potential mentor on the mailing list, not in a 1:1 mail.
Others might have the same questions. Try to do a bit of research before
asking a question that has been answered in the documentation or in the
mailing lists before. This also matters from an Apache standpoint for GSoC
projects.
4. If you get the time or chance, work on smaller PRs before the start of
GSoC to make yourself be known in the SystemML community. People will pay
attention to any PRs you submit.

-Nakul


On Thu, Feb 22, 2018 at 2:58 AM, Krishna Kalyan <krishnakaly...@gmail.com>
wrote:

> Hello Matthias,
> This is a very good list. I would also like to emphasize on starting early.
>
> Cheers,
> Krishna
>
>
>
> On Feb 22, 2018 2:59 PM, "Matthias Boehm" <mboe...@gmail.com> wrote:
>
> > Hi all,
> >
> > first of all, thanks again for your interest. It's great to see that you
> > are excited about our GSoC project idea on language and runtime support
> for
> > parameter servers in SystemML. I'd like to give a couple of pointers to
> > clarify potential questions some of you might have.
> >
> > 1) GSoC Guidelines: There are good existing guidelines. Please read them
> > and make sure that you're eligible.
> > http://community.apache.org/gsoc.html
> > https://google.github.io/gsocguides/student/
> >
> > 2) Project Discussion: For all technical discussions around potential
> > project proposals, let's use the main epic JIRA SYSTEMML-2083. At this
> > stage right now, it's important to understand the general goal, existing
> > related work, and how the proposal would differentiate.
> >
> > Furthermore, think about aspects of the project you would be most
> > interested in. Examples are (1) language and API extensions for a
> seamless
> > integration in SystemML (e.g., paramserv builtin function, Keras2DML
> > extension, function pointers), and (2) runtime support for
> > local/distributed, synchronous/asynchronous execution and related
> > performance features. Both would touch upon SystemML internals but at
> > different abstraction levels. I encourage you to think about how you
> would
> > approach such a sub project. Please don't hesitate to reach out (in
> public
> > or private as you prefer) to discuss your ideas.
> >
> > 3) Optional Contributions: If you are unsure about what it means to work
> on
> > the internals of SystemML, you might want to consider picking up small
> > tasks and simply giving it a try. That's perhaps the best way to get
> > comfortable and to evaluate for yourself if your would enjoy the summer
> > project. There are many open issues some of which are tracked via JIRAs,
> > but we're happy to give more pointed suggestions as well.
> >
> > 4) Project Proposals: After working through the technical aspects and
> your
> > own ideas, you should be in good shape to write your project proposal.
> It's
> > fine to have multiple proposals on the same overall project. At the end
> of
> > the day, its your project
> > proposal that covers your ideas on the how to tackle the overall goal. We
> > are happy to provide feedback though. I would recommend to start early
> and
> > iterate on it.
> >
> > @Nakul and @Krishna: Please correct me if I missed something (since I'm
> > volunteering for the first time as a GSoC mentor).
> >
> > Regards,
> > Matthias
> >
>

Reply via email to