Thanks Paulo, that would be great. And thank you Angelo for raising the problem.
Le jeu. 29 avr. 2021 à 15:13, Paulo Motta <pauloricard...@gmail.com> a écrit : > > 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 > > > > >> > > > > >> > > > > > > > > > >
