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 > >> > >> >
