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: fschue...@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 ?
