> > Might also want to check among the tickets opened by non-committers and > still awaiting an assignee. E.g. > > *assignee is EMPTY AND reporter not in membersOf(Committers)* > > There are patches/pull-requests there too.
Effectively, some people provide patches without assigning the ticket to themselves. :-( Le jeu. 29 avr. 2021 à 14:17, Angelo Polo <language.de...@gmail.com> a écrit : > Might also want to check among the tickets opened by non-committers and > still awaiting an assignee. E.g. > > *assignee is EMPTY AND reporter not in membersOf(Committers)* > > There are patches/pull-requests there too. > > Best, > Angelo > > On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer <ble...@apache.org> wrote: > > > > > > > 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 > > >> > > >> > > >
