> > Berenguer created this board to help to track newcomers contributions: > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463&quickFilter=2088
My apologies, the board was not accessible to most persons. I solved that and everybody should have access to it now. Some committers are appearing in the list because they do not belong to the correct JIRA groups. I opened a ticket to INFRA to solve that problem ( INFRA-21808 <https://issues.apache.org/jira/browse/INFRA-21808>). Nevertheless we have obviously a serious issue because even after removing the committers we have more than 80 non committer patches waiting for reviews. I will try to go through them in the coming weeks to see what happened with those patches and what we can do about them. My hope is that with this new board we can ensure that we provide a timely response to newcomers tickets. Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer <b.le...@gmail.com> a écrit : > 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 >> >>
