Thanks Aleksei,
Some of these are great points, but to respond specifically to the checkstyle
suggestion: I hope to kick off some (minor) discussion around codestyle soon to
modernise our guide, however I would personally prefer that code style
enforcement remains relatively light touch. Some obvious things could be
enforced by checkstyle (such as the braces), and we should investigate that*,
but I would hate for the project to get _too_ mechanical about the way code is
structured.
I've been fairly opposed to the upheaval caused by changing build tooling, but
you're right that the barrier to booting up your IDE is a big part of the
contribution overhead for newbies, so perhaps we should take another look at it.
* I hope to utilise checkstyle soon to prohibit certain specific code patterns
too, but that’s for a much later discussion
On 29/04/2021, 12:05, "Aleksei Zotov" <azotc...@gmail.com> wrote:
Hi Benjamin,
I'd like to put in my two cents as well.
There were many great suggestions related to the communication and
process. They make sense to me, however, I'd like to look at the problem
from another perspective.
First of all, let me share my perception on the opensource activities.
There are two main reasons why people may want to contribute: 1) they
experience a problem on the current project 2) any kind of volunteering.
The first reason is clear, those contributors are not going to stick
around because they just need to solve their particular problem.
The second group of people is our target. In fact, there could be
numerous reasons why people want to contribute (feel bored, get new
experience, improve resume, etc), but despite the particular motivation
point, people should feel positive of what they are doing. For that we
should make sure they feel a part of the team/process and their work
appreciated.
The first point is related to many suggestions that have been already
brought. I feel the most important here is timely replies (even "sorry,
we're busy these days, I'll review/respond in two weeks / after xxx
version is released" is much better than silence). Such "follow up"
responses do not address the original queries, but they help the
external contributors to keep courage and remove uncertainty related to
the lack of transparency (it might not be clear: a) whether the request
is still on someone's radar b) when to expect a response c) when it is a
good time to follow up). And obviously a "real" (or at least another
"follow up") response needs to be provided within the ETA. This still
does not resolve the problem of committers bandwidth, but allows to
handle spikes in requests from the contributors.
Appreciation is the second point. Generally people like making
achievements, we just need to make every contribution a kind of
achievement that a person somehow may boast of. A good way of doing that
is having some rewards. It might be smth material like a T-Shirt (I
remember getting a T-Shirt on C* v2 release was nice; obviously not for
a single commit, but for multiple - depends on the budget; or top 10 the
most active external contributors) or smth free like a virtual badge,
being posted in an annual list of contributors or similar. Even though
it may sound a bit naive, I believe people like making and counting
achievements and it might help to attract/retain the contributors.
On a separate note, there is a technical part of the problem of
attracting (not retaining) the contributors. It is really important to
make sure that the entry level is low enough and people do not spend
much time on additional configuration, learning styling guidelines, etc
for making their first contribution. No-one likes boring stuff :)
Based on my experience among many opensource projects, it is really
frustrating to spend hours of personal time on getting the build working
locally, configuring IDE or similar problems that should not ever exist
(or at least be well documented). I believe that many people loose their
courage and give up on this stage (it is a kind of uncomfortable to ask
for help in running tests in a group chat with 600+ people). For
example, Intellij configuration (/ant generate-idea-files/) did not work
for me (test classpath was missing
<https://github.com/apache/cassandra/commit/c65500e8a1213f194531bbfc77f37f0d7bf270df#diff-bca7bec45f530cfea5a78d707c0e0b3790a547da60a551f1e35b551a8c8d56e9R69>,
imports and formatter configs were not picked up properly) - I fixed it
myself. Netbeans configuration
<https://github.com/apache/cassandra/commit/5578627d74d0c06fcc0f8e1f7a63f7105ccb5d94>
was also broken. All such minor issues are really major if they can
potentially scare away the new contributors.
Even though it might sound too technical, I feel we may greatly benefit
(in term of attracting the new contributors) from the below changes:
- use a generic code style config (https://editorconfig.org/
<https://editorconfig.org/>), it is supported by Intellij, Eclipse and
NetBeans.
- migrate to /maven/, all modern IDEs support it pretty well (/gradle/
might be an option, but I believe it has slightly worse out of the box
integration with IDEs - arguable point). In a combination with the
previous point, there won't be a need to maintain separate IDE-specific
configs. As a result, there are more chances that the IDE configuration
will be kept valid and up-to-date. I understand it is a major effort,
but /ant/ is almost died and this change is anyway inevitable.
- introduce checkstyle (https://checkstyle.sourceforge.io/anttask.html
<https://checkstyle.sourceforge.io/anttask.html>,
https://maven.apache.org/plugins/maven-checkstyle-plugin/
<https://maven.apache.org/plugins/maven-checkstyle-plugin/>) that would
fail the local build if smth is not-well formatted. Almost every project
has its own style preferences (especially C* with its "new line
braces"). Basically discussing style-related stuff on review defocuses
(both contributors and reviewers) from the logic and just wastes time.
So it would be great to automate this part (if style if fine build
passes, otherwise fails).
If there is a need I can volunteer/kick off any of the above points.
I hope this helps!
Thanks,
Aleksei.
On 2021/04/23 14:49:47, Benjamin Lerer <b...@apache.org> wrote:
> Hi Everybody,The Apache Cassandra project always had some issues to>
> attract and retain new contributors. I think it would be great to
change>
> this.According to the "How to Attract New Contributors" blog post (>
> https://www.redhat.com/en/blog/how-attract-new-contributors) having a
good>
> onboarding process is a critical part. How to contribute should be
obvious>
> and contributing should be as easy as possible for all the different
types>
> of contributions: code, documentation, web-site or help with our CI>
> infrastructure.I would love to hear about your ideas on how we can
improve>
> things.If you are new in the community, do not hesitate to share your>
> experience and your suggestions on what we can do to make it easier
for you>
> to contribute.>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
