Just to keep everyone in the loop...
Dmitriy and I had a good conversation today about what else needs to be done
in the Ignite (incubating) to further lower the entrance barrier for new
contributors. So far we have identified the following:
1. need for a public CI: current CI is based on TeamCity ran privately by
GridGain team. While it is a hassle and a disruptive one to move the build
infrastructure to the INFRA's ran Jenkins, there's a need to publicly
expose the "official" project CI & test results.
This effort needs to be hooked up to the artifacts publishing, that Roman
brought up earlier. I am pretty sure that even with CI infra sitting
outside of the builds.apache.org the official build producing and
publishing the artifacts can be executed on the ASF build hosts.
Dmitriy has some ideas on how to solve it and I'll let him to chime in to
avoid broken phone effect.
2. First release. I've learned that community is pretty busy finalizing the
refactoring and changing some APIs in the project and that makes things a
bit liquid. However, even right now the project can be build and deployed
and old API is working as before. Hence, in my opinion, the release can be
cut, although it won't be in the GA quality at the moment. But at least it
will be something the users can try on. It also will create an invaluable
experience for all involve, and will demonstrate what does and doesn't
work in the release process.
3. community growth: what is essential, in my opinion, is to be able to
spread the word about the project and be essentially able to recruit new
contributors to the project and the community.
All sorts of communication channels could be used for it: website updates,
blogs, twitting, meetups, hackathons, and so on. I believe the dev@ list
is an important tool in this: lively discussions about the on-going
development should attract more attention and participation from others.
How about start using dev@ for the engineering communication? If this is
done using internal emails - it won't be much of a help to involve a wider
audience into the community. E.g. people need to learn that there's such a
project and see what's going on there. They should be willing to spend
their time on it. But it is essential that a contribution shouldn't come
with a steep learning curve of how to make one; a new-comer should have an
easy way to submit a patch and have it automatically validated by same
official project CI. That's where a well-documented development process -
Wiki or just a website - comes to mind: a simple "How To Contribute" page
would be a great start.
And of course a reliable release process will help with the matter.
Hey, I understand that I might be pushing for a lot ;) And it doesn't have to
be done over night. But these are essential steps to think about and make.
Can other mentors chime in here, pretty please? Did I miss something else? How
the "recruiting process" can be improved?
--
Take care,
Cos
