Re: [DICSUSS] Marketing contributions
I was particularly influenced by this mental model of thinking about open source contributions in the past: https://d33wubrfki0l68.cloudfront.net/dfb15f354706fa763ff385e5eea61520bcdcf8bb/1b0fc/assets/media/community-engagement-oss-image.png Related article: https://www.bvp.com/atlas/roadmap-open-source While there's a lot more in the article as it focuses quite a bit on vendors and monetization of open source (which is a somewhat distasteful topic to many in the community here historically), I did find the model in that image pretty compelling. It's fairly github central and proposes the following tiers from least engaged / invested to most: 1. Watchers: aware but not active (stars on gh) 2. Users: Downloading and using the project (dnloads, docker pulls, etc) 3. (my revision) Project Contributors: opening JIRA issues / gh issues, bugfixes, engaging on ML and slack 4. (my addition): Code Contributors: submitting PR's, reviewing code 5. Committers / Maintainers Each group has both different metrics of engagement we as a project could measure to gauge whether our actions are doing a good job encouraging engagement and participation, and each group also has different needs from us. While we 100% should crawl before we walk before we run, I figured this mental model may be useful to others. IMO we're not very strong with encouraging / understanding / engaging groups 1 and 2. The barrier to entry is pretty high due to fixed complexity in the system on 3-5 but I think we do decently well there and/or are improving (status updates, better curated LHF, advent calendar, mentoring, etc). ~Josh On Mon, Jan 17, 2022 at 5:08 PM Melissa Logan wrote: > Thanks Benjamin. Regarding contributors, what you say here makes sense and > we will discuss other ways to highlight, e.g. in the monthly Changelog, > interview them for the site, etc. Same for users. Beyond the case studies > page and Changelog blog, we'll discuss other ways to thank/interact with > them. > > Erick, thanks for your comment in the deck. > > Others please do share input on the plan and ideas/recommendations section > so we can best support. Thanks, all! > > > On Fri, Jan 14, 2022 at 2:42 AM Benjamin Lerer wrote: > >> Sounds great. By community, do you mean both those who build and/or use >>> C* (or just the folks on dev list)? There are a number of ways we can >>> showcase this. And is there a general goal of growing the number of >>> contributors and/or committers? We worked with Ekaterina last year to get >>> this piece published and could do more of the same: >>> https://opensource.com/article/21/5/apache-cassandra. >> >> >> I see 4 circles in our community: users, contributors, committers and PMC >> members. We officially recognize the transition to the committer status or >> to the PMC member status through emails from the PMC members and some >> public announcement but we do not do anything for contributors. It is an >> area where I believe we should improve. Contributing requires some effort. >> We should officially recognize those efforts and let people know that we >> noticed and are thankful for that. >> Some simple things like mentioning first contributions in our monthly >> updates or Tweeting about them. Thanking people for their constant effort >> through time. I see some people that keep on answering questions on our >> user mailing list and we never really talk about it even if they do an >> amazing job. I see them as important contributors and it is important to >> officially recognize our contributor circle. >> Regarding our users, I feel that we need to thank them for their trust >> more often and open the door for as many exchanges as possible. >> >> >> Le jeu. 13 janv. 2022 à 19:23, Melissa Logan >> a écrit : >> >>> Thanks, Benjamin! >>> >>> > One critical part that we should try to put more forward in 2022 is >>> the community. On Twitter people are quite responsive to it. We have a >>> great community and we should make sure that people feel that they belong >>> to it. >>> >>> Sounds great. By community, do you mean both those who build and/or use >>> C* (or just the folks on dev list)? There are a number of ways we can >>> showcase this. And is there a general goal of growing the number of >>> contributors and/or committers? We worked with Ekaterina last year to get >>> this piece published and could do more of the same: >>> https://opensource.com/article/21/5/apache-cassandra. >>> >>> > I know that pushing content to the website has been a frustrating >>> issue. My understanding is that the problem was in fact more due to our >>> tooling and to the ongoing work on the documentation than to the >>> availability of committers. I do believe that the situation will improve in >>> the future. 🤞 >>> >>> In the past tooling had been a factor which continues to improve. We do >>> still see lag times and have started flagging when they come up, e.g. >>> https://github.com/apache/cassandra-website/pull/75/commits/c80cb86ea86dbde
Re: Google Summer of Code 2022 - Kick-off
Just as an update as it is Friday, I have heard back from about 3 interested mentors, with ideas mainly in the area of testing & performance. But I'm still struggling to get everyone unlocked from their other priorities to spend a few hours on finding or creating new jira tickets for GSOC projects. I'm optimistic we will get to it before the end of the month and I'll keep you updated through next week. henrik On Wed, Jan 19, 2022 at 3:20 PM Paulo Motta wrote: > Thanks Henrik. I will send another thread shortly with more details on how > to volunteer to be a GSoC mentor as well as submit project ideas. > > Em dom., 16 de jan. de 2022 às 19:13, Henrik Ingo < > henrik.i...@datastax.com> escreveu: > >> Hi Paulo >> >> In my experience, it works best when the mentoring organization is clear >> about who is the mentor, and what is the project each mentor will be >> mentoring. >> >> Tomorrow is MLK day in the US, but let me talk to some people and >> get back to you around Wednesday. GSoC is a great opportunity to get new >> contributors to a project. I'll talk to a few people to figure out how we >> could prioritize this during January. >> >> henrik >> >> On Fri, Jan 14, 2022 at 2:52 PM Paulo Motta >> wrote: >> >>> Hi everyone, >>> >>> I'd like to follow-up on this as GSoC timeline starts soon in February >>> [1]. >>> >>> We didn't get any project ideas tagged with the 'gsoc' label in the past >>> 2 months, except Aleksandr Sorokoumov which sent me some tickets for >>> offline triaging. This may indicate this model of having potential mentors >>> register project ideas may not be working too well. >>> >>> I'd like to propose having students triage unassigned tickets and >>> propose projects to potential mentors in the mailing list. >>> >>> We could create a blog post with a "Call for GSoC Projects" with >>> instructions on how to triage tickets on JIRA and propose project ideas in >>> the mailing list, and a twitter campaign pointing to the blog post. >>> >>> What do you think? >>> >>> Paulo >>> >>> [1] - https://developers.google.com/open-source/gsoc/timeline >>> >>> Em sex., 12 de nov. de 2021 às 11:30, Paulo Motta < >>> pauloricard...@gmail.com> escreveu: >>> We made an announcement about GSoC on our twitter account (@cassandra) with a call to action for potentially interested people to reach out on #cassandra-dev. I kindly ask everyone to refer prospective GSoC contributors to LHF tickets and getting started pages so they can get involved with the project before the official project ideas are released. Also, please retweet this to get the word out: https://twitter.com/cassandra/status/1459163741002645507 Chers, Paulo Em sex., 12 de nov. de 2021 às 08:24, Berenguer Blasi < berenguerbl...@gmail.com> escreveu: > Agreed thx a lot. > > On 12/11/21 10:02, Benjamin Lerer wrote: > > Thanks a lot Paulo for pushing that forward. That is a great way to > grow > > our community. > > > > Le jeu. 11 nov. 2021 à 14:32, Paulo Motta > a > > écrit : > > > >> Hi, > >> > >> The Google Summer of Code organization announced some exciting > changes to > >> the program next year [1]: > >> (1) Starting in 2022, the program will be open to all newcomers of > open > >> source that are 18 years and older, no longer focusing solely on > university > >> students. > >> (2) GSoC Contributors will be able to choose from multiple size > projects > >> ~175 hour (medium) and 350 hour (large). > >> (3) We are building increased flexibility around the timing of > projects - > >> there is an option to extend the standard 12 week coding time frame > to a > >> maximum of 22 weeks. > >> > >> I wanted to take this announcement to kick-off the preparation for > our > >> participation in the program next year as a means of attracting and > >> mentoring new contributors to our community. > >> > >> The earlier we attract prospective "GSoC Contributors" the higher > the > >> chances of a successful project and retaining the contributors > after the > >> program. > >> > >> The best GSoC project ideas are those which are self-contained: > have a well > >> defined scope, discreet milestones and definition of done. > Generally the > >> areas which are easier for GSoC contributors to get started are: > >> - UX improvements > >> - Tools > >> - Benchmarking > >> - Refactoring and Modularization > >> > >> I would like to invite contributors to start tagging issues in JIRA > with > >> the "gsoc" tag as a means of indicating that particular task can be > >> potentially turned into a GSoC project. > >> > >> With the large volume of CEPs being voted and approved recently, it > would > >> be great if a portion of the "nice-to-have" subtasks
Call for Build Lead volunteers
Cwiki article: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 The previous ML thread about this got derailed by the ever exciting topic of our merge strategy. Let's not do that here. :) Simply calling for volunteers to help take on this role starting the week of Jan 31. I predict it'll be ongoing <= 30 min of maintenance a day (once I catch up on our backlog next week), 2.5 hours a week. 6.25% of a 40 hour work week. I'll be sure to really kick the tires and hopefully iron out most of the obvious bugs in the docs and process as well as get a PR to our docs for the official C* site for this process before the next round. Thanks in advance! ~Josh
[DISCUSS] Patching, versioning, and LTS releases
I took a stab at codifying a lot of what we've talked about in terms of "what code goes where" that's tribal knowledge thus far undocumented on our project; I've had another long-timer review it and I think it's ready for broader community input. Roughly 1 page, quick reading, should all be stuff we mostly know and agree upon. Link: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302 Thanks. ~Josh
Re: Call for Build Lead volunteers
I have taken the next available week of 1/31. On Fri, Jan 21, 2022 at 8:29 AM Joshua McKenzie wrote: > > Cwiki article: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 > > The previous ML thread about this got derailed by the ever exciting topic of > our merge strategy. Let's not do that here. :) > > Simply calling for volunteers to help take on this role starting the week of > Jan 31. I predict it'll be ongoing <= 30 min of maintenance a day (once I > catch up on our backlog next week), 2.5 hours a week. 6.25% of a 40 hour work > week. > > I'll be sure to really kick the tires and hopefully iron out most of the > obvious bugs in the docs and process as well as get a PR to our docs for the > official C* site for this process before the next round. > > Thanks in advance! > > ~Josh >
Re: UDF future
+1 Best Regards, Aleksei Zotov. On Thu, Jan 20, 2022 at 11:52 AM Marcus Eriksson wrote: > +1 > > On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote: > > Hi everyone, > > > > With the work to add Java 17 support for Cassandra, a new question around > > the future of UDF was raised. The scripted UDF was using Nashorn which is > > no longer packaged with the JDK. There are options to add new > dependencies > > to Graal JS for example but it seems people are not sure that it is worth > > it. Please check the discussion on CASSANDRA-16895. > > > > The following suggestion was made by Marcus and supported by other PMC > > members - "I think we should deprecate scripted UDFs now and drop them > from > > the next major, but possibly provide hooks for people to write their own > > UDF "engines" and break out the current javascript implementation in to > its > > own repository (but not ship it with Cassandra)." > > > > As a result we decided to engage with our users and created a Twitter > > survey. Results below: > > > > *We would love to understand how you use ApacheCassandra UDFs and UDAs.* > > > > *32 people responded as follows:* > > > >- *We do not use them - 75%* > >- *We only use Java UDFs - 22%* > >- *We only use JS UDFs - 0%* > >- *We use Java and JS UDFs - 3%* > > > > We also received feedback on LinkedIN on the topic - > > > https://www.linkedin.com/feed/update/urn:li:activity:6886728406742970369?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6886793921020608512%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6887421509485248512%29 > > > > Thoughts? > > > > Best regards, > > Ekaterina >
Re: Call for Build Lead volunteers
I have taken the second week of February (2/7 - 2/11). Best Regards, Aleksei Zotov. On Fri, Jan 21, 2022 at 6:47 PM Brandon Williams wrote: > I have taken the next available week of 1/31. > > On Fri, Jan 21, 2022 at 8:29 AM Joshua McKenzie > wrote: > > > > Cwiki article: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199527692 > > > > The previous ML thread about this got derailed by the ever exciting > topic of our merge strategy. Let's not do that here. :) > > > > Simply calling for volunteers to help take on this role starting the > week of Jan 31. I predict it'll be ongoing <= 30 min of maintenance a day > (once I catch up on our backlog next week), 2.5 hours a week. 6.25% of a 40 > hour work week. > > > > I'll be sure to really kick the tires and hopefully iron out most of the > obvious bugs in the docs and process as well as get a PR to our docs for > the official C* site for this process before the next round. > > > > Thanks in advance! > > > > ~Josh > > >
