systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niketan Pansare" <npan...@us.ibm.com>
Subject Re: Building a community around SystemML
Date Thu, 29 Sep 2016 00:16:02 GMT

Thanks Luciano and Felix for starting this discussion.

+1 for versioned documentation.

Regarding understanding the SystemML internals, following things would
help:
1.  I believe we have done a good job to separate the components into
different package as well as modularize the compilation process in separate
layers. Though the components/layers are well-explained in our papers, it
might be a good idea to create design document as suggested by Felix. This
design document should explain different component and also the interface.
May be putting the design into javadoc with links/references and then
hosting the docs might be a good idea too. This will help in reviewing the
PR itself as the code and docs are in the same file.

2. We can showcase following videos on
https://apache.github.io/incubator-systemml/contributing-to-systemml:
- SystemML classes (example:
https://www.youtube.com/playlist?list=PL9U7gw7DOIGhdiKZkMAqNPIDywFMlzCaY)
- Meetups (
https://www.youtube.com/watch?v=WkYqjWL1xzk&index=13&list=PL9U7gw7DOIGiT4yi2uw_Mk3TbBEDc_qKq
 and https://www.youtube.com/watch?v=hJfubEYDiQ8 and
https://www.youtube.com/watch?v=6VpiJK8Jydw)
- Code walkthrough videos (example:
https://www.youtube.com/watch?v=2dnIKY1iVCI and
https://www.youtube.com/watch?v=niz1VLrrucQ ... very old videos ... would
recommend creating new ones instead).
- Demos.

Thanks,

Niketan Pansare
IBM Almaden Research Center
E-mail: npansar At us.ibm.com
http://researcher.watson.ibm.com/researcher/view.php?person=us-npansar



From:	fschueler@posteo.de
To:	dev@systemml.incubator.apache.org
Date:	09/28/2016 03:50 PM
Subject:	Re: Building a community around SystemML



I think those are excellent ideas! Especially the point about
communicating on the mailing-list.

Google summer of code is a great way of getting people involved with the
project long-term and we should think about possible projects.
Application for mentoring organizations usually starts in February. I
would be open to help planning this.

For the personas and documentation I agree. Good documentation should be
a priority and something like a "Quickstart" should be the first goto
for many people that want to try SystemML. Apart from that, the current
documentation is in a somewhat unstable state since it mixes
documentation for different releases, APIs, languages, etc.
Maybe we could aim for a versioned documentation that is part of a
release and can be easily related to the corresponding release. It
should be easy for users to find the docs that correspond to the version
of SystemML that they're using (similar to Spark's documentation link on
spark.apache.org). Making documentation part of a PR that affects user
APIs might be a good idea.

Regarding the Jiras, I think it's important to include enough
information in their description. Similarly, it might be helpful for new
contributors to have an overview of SystemML internals that don't
require them to read all related papers. When we investigated SystemML
internals for the Flink and DSL implementation, it took us a long time
to understand the places in the code that we had to touch before we
could get started. In the course of this I started writing down a few
things in a google doc
(
https://docs.google.com/document/d/139lRYxrD-j1k1Fh7X4jVkMZypbqS_8ZskN3PiZgjKVE/edit#heading=h.q6w9j5yjre8y
).
It might make sense to extend that to give users a high-level but
detailed enough overview of SystemML that lets them understand what the
components are and how they interact. This might help people to figure
out what they would want to work on, too.

Felix


Am 28.09.2016 21:32 schrieb Luciano Resende:
> One of the remaining things that SystemML needs to do in order to
> graduate
> is to build a better community around the project.
>
> Some ideas are:
>
> - Be more open with mailing lists discussions particularly with high
> level
> designs that sometimes just get buried in PRs.
> - Identify and participate on projects where more experienced community
> members would mentor students or others interested in
> participating/contributing to the project (e.g. GSoC)
> - Identify top two main personas that would be interested in the
> project,
> and bring up visibility on documentation based on these personas to
> make
> their first experience with the project very smooth and without much
> problems.
> - Create simple JIRAs and flag them for initial contributors (e.g.
> documentation, simple fix, etc)
>
> Any other ideas ? And how do we execute this with some priority to get
> us
> to graduate ?




Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message