Thanks for the feedback Aleksei, 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.
It seems that we will need to find some sponsors for some t-shirt ;-) We definitely need to have some T-shirts for 4.0!!! If there is a need I can volunteer/kick off any of the above points. > Please do. Feel free to fire some discussions on the dev list to discuss each of those points. Simply take care to do it for one subject at a time as people might have some trouble to follow all the discussions going on otherwise. Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith <bened...@apache.org> a écrit : > 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 > >
