> Effectively, some people provide patches without assigning the ticket to themselves. :-(
I will try to think of an automation in the context of the JIRA hygiene effort that detects this and sends an automatic message asking the person to set themselves as assignees. Em qui., 29 de abr. de 2021 às 09:52, Benjamin Lerer <b.le...@gmail.com> escreveu: > > > > 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 > > > >> > > > >> > > > > > >
