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 ?
