Community Over Code EU CFP closing soon!

[rbowen]

This is your reminder that the Community Over Code CFP will be closing
in about a week - on January 12th. The Community track is still seeking
talk submissions. We already have some great content submitted for the
track, but if you want to get your talk in there, you're running out of
time. Submit your talk TODAY at https://eu.communityovercode.org/  

Priority is given to talks submitted earlier, because we've already
started reviewing.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Community Over Code EU Community track - volunteers requested

[rbowen]

On Thu, 2023-12-21 at 08:19 +0100, Nasser Kaze wrote:
> Hi Rich,
> 
> If it’s not too late, I would also like to help.

It's not too late. We haven't even started yet. :)


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [DISCUSS] How about hosting discourse as an alternative way for mailing list?

[rbowen]

On Wed, 2023-12-20 at 14:26 +0800, Xuanwo wrote:
> **Other solutions?**
> 
> We could also consider hosting a modern frontend for our mailing
> list, similar to Hyperkitty. For instance, take a look at:
> https://ml.ruby-lang.org/mailman3/hyperkitty/list/ruby-t...@ml.ruby-lang.org/

Yes, but we *have* one of those. It's at lists.apache.org 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Community Over Code EU Community track - volunteers requested

[rbowen]

Are any of you interested in assisting me in being the track chair for
the community track at the Community Over Code Bratislava event?
Otherwise I'll just select all my own talks. (Just kidding.)

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [DISCUSS] How about hosting discourse as an alternative way for mailing list?

[rbowen]

On Tue, 2023-12-19 at 19:23 +0800, tison wrote:
> +cc comdev
> 
> Maybe you will be intested in this new type communication.

I would encourage you to take this up with Infra. I am certain that
this has come up before, and that Infra has already done some research
into Discourse, not only in terms of hosting it for projects, but for
the Foundation as a whole, and have thoughts about the sustainability
of doing this in individual VMs vs some kind of service provider. I
don't know what their advice will be, but they are definitely the right
folks to ask for that advice.



> Xuanwo  于2023年12月19日周二 19:15写道：
> > 
> > > Discourse will provide us an incoming email address. All email
> > > sent to
> > > this address will become a post in discourse. We need to add this
> > > address into the dev@o.a.o's subcriber list.
> > 
> > This is talking about Discourse SaaS which cost about $100 ($50 if
> > we have non-profit discount).
> > 
> > If we can request a vm from ASF Infra, we will need:
> > 
> > - VM with 4C8G
> > - Postgresql
> > - A SMTP account to send mails
> > - A domain like discuss.opendal.apache.org
> > 
> > On Tue, Dec 19, 2023, at 18:55, Xuanwo wrote:
> > > > Does it need any configuration from the mailing list part,
> > > > i.e.,
> > > > involve INFRA setup?
> > > 
> > > Discourse will provide us an incoming email address. All email
> > > sent to
> > > this address will become a post in discourse. We need to add this
> > > address into the dev@o.a.o's subcriber list.
> > > 
> > > No another setup needed, AFAIK.
> > > 
> > > We need some test and demo to make sure everything works as
> > > expected.
> > > At the time of writing, I don't know how to do that.
> > > 
> > > On Tue, Dec 19, 2023, at 18:19, tison wrote:
> > > > > called mailing list mode
> > > > 
> > > > Does it need any configuration from the mailing list part,
> > > > i.e.,
> > > > involve INFRA setup?
> > > > 
> > > > I don't know how this happen but as long as we have a readable
> > > > copy on
> > > > the dev@ mailing list, other integration as view can be OK.
> > > > 
> > > > Best,
> > > > tison.
> > > > 
> > > > Jun Ouyang  于2023年12月19日周二 18:16写道：
> > > > > 
> > > > > Hi xuanwo:
> > > > > That’s great! I strongly agree with this change. But I have a
> > > > > concern about
> > > > > markdown support sync to Maillist, It seems will cause more
> > > > > bad experiences
> > > > > for Maillist users.
> > > > > 
> > > > > *GPG public key: 4A6D297E6F74638E4D5F8E99152AC7B5F7608B26*
> > > > > *Thanks,*
> > > > > *Jun Ouyang*
> > > > > 
> > > > > 
> > > > > On Tue, Dec 19, 2023 at 17:36 Xuanwo 
> > > > > wrote:
> > > > > 
> > > > > > Hi, all opendal community members
> > > > > > 
> > > > > > I'm thinking about hosting discourse as an alternative way
> > > > > > for mailing
> > > > > > list.
> > > > > > 
> > > > > > Discourse has a feature called mailing list mode. After
> > > > > > enabling this
> > > > > > feature, we will sync every post between our mailling list
> > > > > > and discourse.
> > > > > > 
> > > > > > - Users can create/reply to posts created in discourse via
> > > > > > email.
> > > > > > - Users can create/reply to posts send by email in
> > > > > > discourse.
> > > > > > - Users can search all posts in discourse.
> > > > > > 
> > > > > > By adding this new alternative, I can see the following
> > > > > > benefits:
> > > > > > 
> > > > > > - All discussion still happen and archived on mailing list
> > > > > > (here).
> > > > > > - Users like mailing list can still uses mailing list
> > > > > > without any change.
> > > > > > - Users like forums can use discourse instead.
> > > > > > - Users don't need to subscribe the email list first before
> > > > > > asking
> > > > > > questions.
> > > > > > - Markdown support, Full-text search support, better
> > > > > > UI/UX...
> > > > > > 
> > > > > > What do you think? Do you want this alternative?
> > > > > > 
> > > > > > Xuanwo
> > > > > > 
> > > 
> > > --
> > > Xuanwo
> > 
> > --
> > Xuanwo
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Fwd: RE: ASF Survey

[rbowen]

Hey, folks,

I assume most of you saw the survey that was forwarded to the
committers@ list a couple of weeks ago. The researcher has requests
further promotion of their survey. I already received some pushback for
sending to committers@ once, and have declined to do so again. But if
we could promote the survey at FOSDEM, or other in-person event, in the
coming weeks, that would be great. Does anyone have the
time/inclination to follow up on this?

--Rich

 Forwarded Message 
From: "Daniel, Sherae (daniesr)" 
To: Rich Bowen 
Cc: Brian Proffitt , "Chen, Liwei (chenlw)"
,  Brian.Fitzgerald ,
Rich Bowen 
Subject: RE: ASF Survey
Date: 12/16/2023 09:00:51 AM

> 
> 
> Hi Rich:
>  
> Thanks for the quick response.  We also appreciate a willingness to
> brainstorm around this issue.  I like the two options that your
> proposed: 1. Reaching out to the comdev mailing list for ideas and 2.
> advertising at an in person conference.
>  
> We have seen other academics who have has some success with ASF
> developers with large followings posting links to the survey on their
> social media accounts.  We were also thinking about trying to reach
> out to specific projects/communities within ASF.  We are unsure
> whether to pursue these things because we also don’t want to
> overstep.
>  
> Should we set up a call to discuss our ideas with you or should we
> wait for you to work on the opportunities with the comdev mailing
> list and circle back in a few days?
>  
>  
> We are so happy to be working with you!
> Sherae
>  
> 
> 
> 
> Sherae Daniel, Ph.D.
> 
> Associate Professor
> 
> Lindner College Ph.D. Program Director
> 
>  
> 
> Recent Research
>  
> 
> Tanyel, N., Windeler, J., andDaniel, S.L. “Don’t Marginalize Me: How
> Organizations Facilitate Social Injustice Via Social Media”in the
> proceedings of the International Conference on Information Systems,
> Copenhagen, Denmark, 2022
> 
>  
> 
> 
> 
> Daniel, S.L., Sanni, S., and Rhue, L. “A Power-threat View of The
> Role of Neighborhood Demographics on Airbnb Review Sentiments” in the
> proceedings of the Americas Conference on Information
> Systems,Minneapolis, Minnesota, 2022. *AMCIS 2022 Best ERF Paper
> Award
> 
>  
> 
> Samuel, B., Bala, H.,Daniel, S.L. Venkataraman, R. (2021)
> “Deconstructing the Nature of Collaboration in Organizations Open
> Source Software Development: The Impact of Developer and Task
> Characteristics”IEEE Transactions on Software Engineering.
> 
>  
>  
> 
> 
> 
> 
> From: Rich Bowen  
> Sent: Saturday, December 16, 2023 8:49 AM
> To: Daniel, Sherae (daniesr) 
> Cc: Brian Proffitt ; Chen, Liwei (chenlw)
> ; Brian.Fitzgerald ;
> Rich Bowen 
> Subject: Re: ASF Survey
>  
> External Email: Use Caution
> 
> 
> 
> 
> 
> 
> 
> 
> Hi folks. We are very sparing in our use of the all-committers
> distribution list since it is a mandatory list for all participants
> in our projects. However, perhaps there are other places we could
> publicize. I will take this over to the comdev mailing list and see
> what we can come up with. The most obvious thing off the top of my
> head is that we could have a sign at the upcoming fosdem event in
> Brussels at the beginning of february.
> 
> 
>  
> 
> 
> Rich
>  
> 
> 
> 
> 
> On Sat, Dec 16, 2023, 08:25 Daniel, Sherae (daniesr)
>  wrote:
> > Hi Rich:
> > 
> > Can we send a final reminder to the list?  It will enable us to get
> > the sample that we need for a robust study and enable us to
> > complete our research protocol.
> > 
> > Thanks so much in advance and happy holidays!
> > 
> > Sherae Daniel, Ph.D.
> > Associate Professor
> > Lindner College Ph.D. Program Director
> > 
> > Recent Research
> > 
> > Tanyel, N., Windeler, J., and Daniel, S.L. “Don’t Marginalize Me:
> > How Organizations Facilitate Social Injustice Via Social Media” in
> > the proceedings of the International Conference on Information
> > Systems, Copenhagen, Denmark, 2022
> > 
> > Daniel, S.L., Sanni, S., and Rhue, L. “A Power-threat View of The
> > Role of Neighborhood Demographics on Airbnb Review Sentiments” in
> > the proceedings of the Americas Conference on Information Systems,
> > Minneapolis, Minnesota, 2022. *AMCIS 2022 Best ERF Paper Award
> > 
> > Samuel, B., Bala, H., Daniel, S.L. Venkataraman, R. (2021)
> > “Deconstructing the Nature of Collaboration in Organizations Open
> > Source Software Development: The Impact of Developer and Task
> > Characteristics” IEEE Transactions on Software Engineering.
> > 
> > 
> > -Original Message-
> > From: Brian Proffitt 
> > Sent: Thursday, December 14, 2023 10:21 AM
> > To: Daniel, Sherae (daniesr) 
> > Cc: Chen, Liwei (chenlw) ; Brian.Fitzgerald
> > ; Rich Bowen 
> > Subject: Re: ASF Survey
> > 
> > External Email: Use Caution
> > 
> > 
> > Looping in Rich Bowen from our Comdev community for different
> > ideas.
> > 
> > BKP
> > 
> > On Thu, Dec 14, 2023 at 10:19 AM Daniel, Sherae (daniesr)
> >  wrote:
> > > 
> > > Hi Brian:
> > > 
> > > Thank you so much for your 

Re: Ask about opportunities to become an Apache Volunteer

[rbowen]

On Mon, 2023-12-11 at 16:33 +, Chi Huiyang wrote:
> 
> 
> 
> Hi developer:
>  
>  
> This is Hannah, master student from UIUC. I'm looking forward a
> employee letter by doing the volunteer work since I need an
> employment letter to support my OPT to stay in United States.
>  
> In my last semester of school, I did many works to contribute to
> Apache by improving the reliability of the systems. My PR had been
> accepted by ActiveMQ, Wicket, Curator, etc. With the internship
> experience in AI, security, as well as development experience with
> Java/Database/Cloud tools, I'm poised to contribute to Apache
> foundation by being a software developer.
>  
>  
> My resume will be attached and Here is my github page :
> https://github.com/MyEnthusiastic

Thanks so much for reaching out to us.

As you've already experienced, volunteering for work at the Apache
Software Foundation is done by just doing it. It sounds like you've
already successfully become part of several projects - getting PRs
accepted by a project makes you a part of those projects already.
Congratulations.

We have a document here -
https://community.apache.org/contributor-ladder.html - that discusses
the "ladder" of progress through Apache projects, and it all comes down
to one thing - doing the work. As you do the work, you will gain trust
in the community/project that you want to work on. That, in turn, will
result in increased responsibility and leadership.

No project is going to look at your resume. Rather, they will look at
your contributions to that project.

So ... welcome. We look forward to seeing more of you in the coming
months and years.

--Rich


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Voice of Apache (Feathercast) recording times available this week

[rbowen]

On Thu, 2023-12-07 at 19:03 +, B C wrote:
> What are the interviews for?

It's another outlet for information and marketing about topics related
to the Apache Software Foundation. See https://feathercast.apache.org/
for examples of what we have published in the past.

--Rich


> 
> Get Outlook for Android
> 
> From: rbo...@rcbowen.com 
> Sent: Tuesday, December 5, 2023 11:00:13 AM
> To: dev@community.apache.org 
> Subject: Re: Voice of Apache (Feathercast) recording times available
> this week
> 
> On Tue, 2023-12-05 at 16:38 +, Gláucia Esppenchutz wrote:
> > Hi Rich,
> > 
> > That's a fantastic idea :)
> > Can we speak a bit about how important is diversity topic in
> > technology? I
> > can't do it this year but count with me in January or February.
> > I will try to reach some people in this area if everyone agrees :)
> 
> I'd be glad to put this on my list for January, then.
> 
> --Rich
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Voice of Apache (Feathercast) recording times available this week

[rbowen]

On Tue, 2023-12-05 at 16:38 +, Gláucia Esppenchutz wrote:
> Hi Rich,
> 
> That's a fantastic idea :)
> Can we speak a bit about how important is diversity topic in
> technology? I
> can't do it this year but count with me in January or February.
> I will try to reach some people in this area if everyone agrees :)

I'd be glad to put this on my list for January, then.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Voice of Apache (Feathercast) recording times available this week

[rbowen]

Hi, folks.

Yet again, I am going to try to get some Feathercast recordings done on
a regular basis and get back into the habit.

(FYI: I am temporarily using the name "Voice Of Apache" rather than
Feathercast, while the logo/branding process is ongoing. I don't know
what name we will settle on long-term, and am awaiting guidance from
M&P on that matter.)

I've got recording times available on Thursday and Friday, and I know
there's some folks here on this list who have indicated interest and
availability to interview on your favorite project/topic. Let me know.

After Cassandra Summit (next week) I'll start reaching out directly to
projects again.

If you are interested in hosting interviews, please do let me know.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Reminder: CFP for Community Over Code Europe is now open

[rbowen]

The Community track at Community Over Code Europe is currently open,
and will be open for just a little more than another month. We would
appreciate your submissions on all topics related to community at the
ASF. This includes governance, community building, working in and with
companies on ASF projects, policy, and other related topics.

Thanks!

https://sessionize.com/coceu-2024/

--Rich, for the Community Over Code planners


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [website] Sample presentations

[rbowen]

On Thu, 2023-11-09 at 10:45 -0500, rbo...@rcbowen.com wrote:
> I'm looking at https://community.apache.org/speakers/slides.html and
> I
> have to admit, I hate it. I would like to rearrange it by topic,
> rather
> than as a list of names that 99% of our audience won't recognize.
> 
> My question is, do you think that folks will be offended if I remove
> their names as the primary headers on this page? (Authors can,
> obviously, still be attributed next to the various links.)


I've taken a first cut at this here:
https://github.com/apache/comdev-site/pull/144

Would appreciate a glance by a couple of people, as to whether these
categories make sense. Thanks.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [website] Sample presentations

[rbowen]

On Thu, 2023-11-09 at 10:45 -0500, rbo...@rcbowen.com wrote:
> I'm looking at https://community.apache.org/speakers/slides.html and
> I
> have to admit, I hate it. I would like to rearrange it by topic,
> rather
> than as a list of names that 99% of our audience won't recognize.
> 
> My question is, do you think that folks will be offended if I remove
> their names as the primary headers on this page? (Authors can,
> obviously, still be attributed next to the various links.)


Stepping back a bit ... I suppose the question I would ask about this
page is, what is the *goal* of the page?

If the goal is "give people a place to show off their conference
appearances" then that's what it's doing.

If, on the other hand, the goal is to provide recommended sample
presentations for folks to 1) learn from and 2) use as starter content
for their own presentations on these topics, then I think it fails
pretty spectacularly.

Having 73 variations of "The Apache Way" is confusing and frustrating.
Meanwhile, our attempts to collaborate on one canonical version have
resulted in
https://training.apache.org/presentations/comdev/apache-intro/ which I
think is what we *should* be promoting.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

[website] Sample presentations

[rbowen]

I'm looking at https://community.apache.org/speakers/slides.html and I
have to admit, I hate it. I would like to rearrange it by topic, rather
than as a list of names that 99% of our audience won't recognize.

My question is, do you think that folks will be offended if I remove
their names as the primary headers on this page? (Authors can,
obviously, still be attributed next to the various links.)

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: VP Conferences changes

[rbowen]

On Wed, 2023-11-08 at 06:33 -0800, Owen Rubel wrote:
> Weak sauce. Once marketing takes over, conference talks become merely
> part
> of SALES.
> 
> ApacheCon has been about learning... not SALES and MARKETING.

I'm honestly torn as to whether this troll-y message merits a response.

I'd expect someone with your deep experience in tech (This
you? https://www.linkedin.com/in/owen-rubel-531197228/) to understand
that sales and marketing are fundamentally different things.

Events are fundamentally about *messaging* which is what marketing is
about. Marketing has been an equal partner in the production of this
event since the first one in 1998.

We don't have products, and thus we have no sales.

As always, you are more than welcome to come participate in the
planning activities if you wish to shape that messaging.

> On Wed, Nov 8, 2023 at 4:04 AM Rich Bowen  wrote:
> 
> > Fyi, effective yesterday, I have stepped down as VP conferences.
> > The
> > responsibility for that role has passed to VP marketing, but
> > communication
> > around conferences will still happen on the planners mailing list,
> > as it
> > has for many years.
> > 
> > It's my hope to get a little more engaged on the side of the house,
> > which,
> > of course, I've been trying to do for the last couple of years.
> > 
> > Rich
> > 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Community building advice

[rbowen]

Hi, folks,

As discussed various times on Slack, I am planning to create some
concrete, practical advice to our project communities about how to grow
their developer communities. I've put a bullet list here -
https://community.apache.org/communitybuilding/ - and will be
developing that over the coming year (I hope).

I have become more than a little concerned about trends that I'm seeing
across the Foundation: Super-high committer bars with no real
justification; Ignoring contributors, who then eventually go away in
frustration; Off-list discussions that are then never discussed in the
view of the community; Committer/PMC elections influenced by company
affiliation/role rather than by public discussion. I am hoping that we
can address some of these by education, and by having "official" pages
that we can point to when projects are learning how to be ASF
projects. 

Yes, some of this happens in the Incubator. My concern is post-
incubator, when the decision-makers on the project arrives post-
incubator, and so don't benefit from that experience. A second-
generation problem, you might say.

Anyways, as always, I welcome and appreciate your participation in
writing this stuff, and in organizing it.

Thanks.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Project "on call"

[rbowen]

I wanted to draw attention to the bRPC project, which has a community
"on call" rotation, which is documented here:

https://brpc.apache.org/docs/community/on-call/

It's worth keeping this in mind and mentioning it to other projects who
come looking for ways to make their projects more welcoming to
beginners.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Helping to welcome non-english communities by questioning our rules?

[rbowen]

On Thu, 2023-10-26 at 07:42 +, Christofer Dutz wrote:
> We have this rule: If it didn’t happen on the list, it didn’t happen
> (Don’t even know if it’s really written down somewhere or if it’s
> just a common mantra).

It's written here:
https://community.apache.org/newbiefaq#NewbieFAQ-IsthereaCodeofConductforApacheprojects
?

And here: https://incubator.apache.org/guides/committer.html

Whether those constitute "policy" or just best practice is left as an
exercise for the reader.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: patch and reboot of projects-vm

[rbowen]

On Thu, 2023-10-26 at 09:25 -0400, Chris Thistlethwaite wrote:
> Greetings!
> 
> I'd like to patch and reboot your VM today at 20:00 UTC. Unless there
> is a better time, you'd like me to do it ASAP, or there is a conflict
> with the scheduled time. 


Please proceed. We have nothing particularly time-sensitive going on,
and no time is better/worse than another.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Community docathon in Halifax?

[rbowen]

On Fri, 2023-10-13 at 14:27 -0700, Dave Fisher wrote:
> > What's a good way to name this kind of audience, and how could we
> > usefully solicit some stories like this?
> 
> IIRC Sally had developed some material with a handful of vendors.

Can you say more here? What kind of material? Where is it? I have no
recollection of this.



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Approval for project "BoF" get-togethers ?

[rbowen]

On Thu, 2023-10-12 at 10:58 -0400, David Smiley wrote:
> Thanks Richard.  I'll take your response as a Director as overriding
> whatever confusion I have with the published rules.  I was hoping
> your
> perspective would somehow be evident in ASF published rules so that I
> wouldn't have needed to ask on ComDev.  Alas.


I think that, as with many ASF policies, policies are created to
address bad situations, rather than pre-emptively. This has never come
up that I'm aware of, and thus our policy never thought to address it.

So, yeah, we could stand to update that policy to reflect this
feedback. But FWIW, that's *my* policy, as VP Conferences, so whatever
confusion you have with it is *also* on me.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Approval for project "BoF" get-togethers ?

[rbowen]

On Wed, 2023-10-11 at 12:29 -0700, Anshum Gupta wrote:
> I agree with Rich here. Organizing meetups, BoFs, etc. are essential
> for a
> healthy community.
> 
> I would like to clarify though, that the meetups should not claim as
> being
> organized "by the PMC" without a prior notification to the PMC
> (private
> list?).

+1

Indeed, if you're doing these things, you *should* be notifying the dev
list, every single time. I assume you're already doing that.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Building a chatbot over the ASF community website

[rbowen]

On Tue, 2023-10-10 at 20:35 -0300, Enrico Olivelli wrote:
> Hello,
> I am sorry but today at the Lighting talks I wanted to show how to
> build in
> 2 minutes a chatbot that is about to answer to questions about the
> ASF
> community website.
> 
> I didn't know that at the Lightning talks it is possible to show your
> laptop.
> 
> I will put up the demo in a git repo as soon as possible and I will
> share
> it here.
> 
> To run the demo you can you a laptop, and then we can run it on a VM
> somewhere at some point.

Apologies that I did not see this message prior to the event last
night.

By long-standing tradition, we don't do slides at the Lightning Talks,
which is definitely limiting, but also adds to the challenge to make
content engaging in the very short time available.


--Rich



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Approval for project "BoF" get-togethers ?

[rbowen]

On Wed, 2023-10-11 at 02:07 -0400, David Smiley wrote:
> Hello ComDev,
> 
> I'm the Apache Solr PMC chair and I have some brading/trademark
> questions
> pertaining to policies around event organization and ASF rules of
> such.
> 
> I've read:
> [1] Policy for Event names using Apache marks:
> https://www.apache.org/foundation/marks/events.html#events
> [2] Approval of small Apache-related events:
> https://community.apache.org/events/small-events.html
> 
> Question:
> * At ASF Community-over-Code, if someone organizes a Birds of a
> Feather for
> Solr and it gets onto the event schedule, should it be necessary to
> get the
> Solr PMC's approval beforehand?  Would it matter if the person who
> arranged
> it is a PMC member themselves or not?  Please ultimately explain the
> answer
> with a rationale against the current policy.  It's unclear if the BoF
> *itself* is a "small Apache-related event" or if the fact that it's
> at an
> ASF ticketed conference overrides because then the policy wouldn't
> apply at
> all (nothing is "3rd party").

No, I see no need for that degree of process or overhead. Meetups,
BoFs, local gatherings, are no different than chatting over dinner with
friends, and I would *not* want to require PMC oversight there.

The policy is for when the brand is being used to promote something
publicly and there's a chance of confusion that you are somehow
speaking on behalf of the project. A meetup does not have this kind of
potential for confusion.

> 
> * If such a BoF were to be organized at a non-Apache conference (e.g.
> Berlin Buzzwords), presumably Solr PMC permission is needed as
> specified by
> [2].

Even there, I'd say no. Having a "let's get together to talk about
Solr" gathering at All Things Open, or Open Source Summit, does NOT
require the PMC's approval, or even acknowledgement.

Now, if you're a group of project members making *decisions*, then that
must go back to the mailing list to involve the whole community. But
you already knew that.

> 
> An unclear aspect of the policy is what the "event" is -- is it the
> entire
> conference or could it be the proposed BoF talk as well, even though
> it's
> composed as part of another event?  If we're only looking at the
> BoF/talk
> itself, then would it be "3rd party" if the primary speaker is a PMC
> member?  The text at
> https://www.apache.org/foundation/marks/resources
> (search for "third party") seems to contrast PMC members & committers
> in a
> way to imply they are *not* third party.


Interesting question.

I would never consider a BoF "an event" for the purposes of this
policy. Nor would I consider something arranged on meetups.com or
whatever to be "an event". An event implies marketing, tickets, and so
on.

Yes, it's a fuzzy line, but I am not in favor of creating process that
discourages user meetups.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Community docathon in Halifax?

[rbowen]

On Thu, 2023-10-05 at 23:37 -0400, Shane Curcuru wrote:
> A number of us have been working on some very specific community 
> documentation improvements over the past year, and it would be great
> to 
> find time in Halifax to share ideas and energize each other.  Who's 
> going to be there, when might you want to work on this, and what are 
> your ideas?


I'll be attending some of the Sustainability track today, but I'll
mostly be hanging out wherever I can find an outlet and hacking on the
ComDev website. What I would like to do is discuss how to

* Consolidate duplicate pages that have grown organically over the past
10 years
* Organize the site into clearly audience-centric areas
* Identify docs that still need to be written
* Identify overlap with other ASF sites, and figure out where the
*best* place is for that particular content.

> 
> Besides all sorts of editing pages to really focus on writing for the
> average reader (often newcomers on community.a.o pages), I really
> wonder 
> about holistic improvements to information architecture, especially
> ones 
> that normalize and canonicalize all the processes around the ASF way.
> Rich and others have already started great contributor ladder stuff,
> and 
> also eliminating or consolidating duplicate pages.
> 
> One issue I struggle with strategically is: where should different 
> content live?  On one hand, we want to focus on the reader, and meet 
> them with what they need.  On the other hand, we have various 
> communities/officers inside the ASF who either set policy, or perhaps
> just provide advice and best practices.  Where should different
> policies 
> - and documentation thereof - live?
> 
> I think we need to strive towards documentation bits that can be 
> repurposed, or can otherwise serve both as an intro to a whole
> process, 
> as well as a more detailed "why" that process came to be.
> 
> I also think organizationally, we need to decide what lives where and
> make it easier to keep updated.  It often feels like core policies
> and 
> strict requirements primarily need to live on /dev (or /legal, 
> /foundation/trademarks, infra.a.o, etc.), but that they should be 
> shorter, clearer, and more direct about exactly what their policies
> are.
> 
> And then much of the why content, and content that helps draw
> newcomers 
> into thinking about the bigger picture, should primarily live on 
> community.a.o.  If people are curious or want to learn about how we 
> *think* about communities, come to ComDev. But if existing committers
> just want to know how to vote on a release, go to the appropriate and
> simple /dev page that just describes the process.
> 
> I'll be in Halifax thru Wednesday lunchtime, but will mostly be
> speaking 
> and thinking about sustainability all Sunday - including at a 
> Sustainability BOF in the evening.=
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Community docathon in Halifax?

[rbowen]

All of this. Hopefully we can focus on actual achievable goals, and not
spend the entire time falling down philosophical rabbit holes. I
definitely want to be part of this conversation. I very much want Brian
to be part of it too, and we need to be sure not to make sweeping
decisions without bringing Brian and our Constantia friends in on it.
But I think that we can draw some high-level proposal diagrams.

Specifically, I would like to work on turning the community.a.o site
map into more of a tree and less of a maze. I have some concrete plans,
but each time I start digging into it I get lost in the maze and end up
not doing much actual writing. It would be nice to fix that this week.

--Rich

On Thu, 2023-10-05 at 23:37 -0400, Shane Curcuru wrote:
> A number of us have been working on some very specific community 
> documentation improvements over the past year, and it would be great
> to 
> find time in Halifax to share ideas and energize each other.  Who's 
> going to be there, when might you want to work on this, and what are 
> your ideas?
> 
> Besides all sorts of editing pages to really focus on writing for the
> average reader (often newcomers on community.a.o pages), I really
> wonder 
> about holistic improvements to information architecture, especially
> ones 
> that normalize and canonicalize all the processes around the ASF way.
> Rich and others have already started great contributor ladder stuff,
> and 
> also eliminating or consolidating duplicate pages.
> 
> One issue I struggle with strategically is: where should different 
> content live?  On one hand, we want to focus on the reader, and meet 
> them with what they need.  On the other hand, we have various 
> communities/officers inside the ASF who either set policy, or perhaps
> just provide advice and best practices.  Where should different
> policies 
> - and documentation thereof - live?
> 
> I think we need to strive towards documentation bits that can be 
> repurposed, or can otherwise serve both as an intro to a whole
> process, 
> as well as a more detailed "why" that process came to be.
> 
> I also think organizationally, we need to decide what lives where and
> make it easier to keep updated.  It often feels like core policies
> and 
> strict requirements primarily need to live on /dev (or /legal, 
> /foundation/trademarks, infra.a.o, etc.), but that they should be 
> shorter, clearer, and more direct about exactly what their policies
> are.
> 
> And then much of the why content, and content that helps draw
> newcomers 
> into thinking about the bigger picture, should primarily live on 
> community.a.o.  If people are curious or want to learn about how we 
> *think* about communities, come to ComDev. But if existing committers
> just want to know how to vote on a release, go to the appropriate and
> simple /dev page that just describes the process.
> 
> I'll be in Halifax thru Wednesday lunchtime, but will mostly be
> speaking 
> and thinking about sustainability all Sunday - including at a 
> Sustainability BOF in the evening.=
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: ASF booth at OpenSource Experience Paris

[rbowen]

On Wed, 2023-10-04 at 09:27 +0200, Olivier Heintz wrote:
> This booth is free but it's a exchange contract between the booth and
> the future ASF communication action for this event.
> I have some question to the Event organization.
> I can send the contract proposal to anyone want read it (it's in
> french)

You're certainly welcome to send it, but cannot promise what will
happen next, of course, until we read it.

Thanks.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Centralise DOAPs?

[rbowen]

On Fri, 2023-09-08 at 15:30 +0100, sebb wrote:
> On Fri, 8 Sept 2023 at 15:10,  wrote:
> > 
> > On Thu, 2023-09-07 at 23:26 +0100, sebb wrote:
> > > I think it would be worth considering setting up a central store
> > > for
> > > DOAPs.
> > > This was suggested in the past, but was rejected, I think mainly
> > > because PMCs were expecting to have to make regular updates to
> > > DOAPs,
> > > e.g. when releases are made, so wanted to keep them with the
> > > code.
> > > 
> > > It's a pain keeping the releases section of DOAPs up to date
> > > (even if
> > > they are local to code).
> > > Now that there is an automated releases listing, I wonder whether
> > > there is any point keeping the info in the DOAP as well?
> > > 
> > > The rest of the fields in a DOAP rarely change, so it matters
> > > less if
> > > the DOAP is stored in a different repo from the code to which it
> > > relates.
> > > 
> > > If DOAPs were moved to a shared GitHub repo, I think it would be
> > > much
> > > easier for maintenance purposes. Some issues such as fixing an
> > > incorrect repo URL or download page link could be dealt with by
> > > anyone
> > > with suitable karma.
> > > 
> > > Just a thought.
> > 
> > I'm a little torn on this one. It would certainly make it a lot
> > easier
> > for *me*, but at the expense of making it harder for the projects.
> 
> How so?

Just in that they'd have to go somewhere else to maintain this one
piece of data, separate from the rest of their project.

I agree it's not a *big* inconvenience. And also, most projects would
do it once, and then never again.

I may be persuaded. :)

> > I would certainly like to have the ability to address some of the
> > awful
> > phrasing, grammar, and just bad project descriptions, without
> > having to
> > navigate every project's different contribution process.
> 
> And without needing to involve the project unnecessarily.

Yeah, I think I'm persuaded. Particularly if we drop the 'releases'
section of projects.a.o and simply point to the projects' download
pages rather than trying to duplicate data that's already maintained
elsewhere.



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Centralise DOAPs?

[rbowen]

On Fri, 2023-09-08 at 07:20 -0700, Dave Fisher wrote:
> > 
> > If, on the other hand, we are able to extract the frequently-
> > changing
> > stuff (ie, releases) from this data, and reduce it just to the
> > seldom-
> > changing stuff, as you suggest, this would be worth doing. It's not
> > clear to me how big a lift that is, though.
> 
> Every release ever is at http://archive.apache.org/dist/ if it is not
> there then it’s not a release.

Yes, I'm aware of that.

What I'm saying what's not clear is how much work is involved
incorporating that information into projects.a.o - or, indeed, if we
want to at all.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Centralise DOAPs?

[rbowen]

On Thu, 2023-09-07 at 23:26 +0100, sebb wrote:
> I think it would be worth considering setting up a central store for
> DOAPs.
> This was suggested in the past, but was rejected, I think mainly
> because PMCs were expecting to have to make regular updates to DOAPs,
> e.g. when releases are made, so wanted to keep them with the code.
> 
> It's a pain keeping the releases section of DOAPs up to date (even if
> they are local to code).
> Now that there is an automated releases listing, I wonder whether
> there is any point keeping the info in the DOAP as well?
> 
> The rest of the fields in a DOAP rarely change, so it matters less if
> the DOAP is stored in a different repo from the code to which it
> relates.
> 
> If DOAPs were moved to a shared GitHub repo, I think it would be much
> easier for maintenance purposes. Some issues such as fixing an
> incorrect repo URL or download page link could be dealt with by
> anyone
> with suitable karma.
> 
> Just a thought.

I'm a little torn on this one. It would certainly make it a lot easier
for *me*, but at the expense of making it harder for the projects. We'd
also have to go back around to every project to educate about this
change, and address 100 different objections to the change

What would be cool is if Git had something equivalent to svn externals,
so that we could have the best of both worlds. Maybe some day, Git will
catch up to where svn was 10 years ago. ;-)

If, on the other hand, we are able to extract the frequently-changing
stuff (ie, releases) from this data, and reduce it just to the seldom-
changing stuff, as you suggest, this would be worth doing. It's not
clear to me how big a lift that is, though.

I would certainly like to have the ability to address some of the awful
phrasing, grammar, and just bad project descriptions, without having to
navigate every project's different contribution process.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Proposal: Consolidate the various pages about voting/deciding

[rbowen]

On Tue, 2023-05-30 at 15:45 -0400, rbo...@rcbowen.com wrote:
> Proposal: Consolidate the various pages about voting/deciding

See https://github.com/apache/comdev-site/pull/128


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

projects.a.o "maintainer" field

[rbowen]

With some attention on projects.a.o at the moment, I'd like to raise
the subject of the "maintainer" field in the DOAP files. That field
doesn't make sense in ASF-style projects. The "maintainer" is always
going to be the project's PMC.

I came across a few DOAP files that listed an individual name in that
field, and that's misleading, at best.

I'd like to drop 'maintainer' from the DOAP creation form. Are there
any objections to that?


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Incorrect categories in DOAPs

[rbowen]

On Wed, 2023-09-06 at 11:53 +0100, sebb wrote:
> I've just noticed that there are some DOAPs using rather odd
> categories.
> 
> For example 'C', 'PHP', 'Groovy', 'SQL'.
> 
> Seems to me that these are languages, not categories.
> 
> I think these should be disallowed as categories; they just clutter
> the category listings and distort the statistics.
> 
> WDYT?


+1


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: RFC: many PMCs have not provided DOAPs

[rbowen]

On Tue, 2023-09-05 at 17:19 +0100, sebb wrote:
> I doubt it will ever be possible to ensure that fields like releases
> are kept up to date.

It appears that we have *some* projects that update the doap file as
part of their release runbook. But, yeah, not all of them.

With all of the variations in what data *can* be in these files,
verifying that they're current is going to be mostly manual work, I
think.

Meanwhile, we've had 3 new DOAP files so far today, and I'll follow up
in a week or so.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: RFC: many PMCs have not provided DOAPs

[rbowen]

On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote:
> I think a lot of DOAP files may be out of date as well. At least for
> Wicket
> we have moved our site SCM from svn to git a long time ago, but
> didn't
> realise that project.a.o needed updating.
> 
> Suffice to say, Wicket has had several (major and minor) releases
> since
> 2015-02-02...

Hmm. Isn't that information available somewhere else, without having to
manually update a file?

But, yeah, this is a great point. Thanks for mentioning it.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: RFC: many PMCs have not provided DOAPs

[rbowen]

On Tue, 2023-09-05 at 09:03 -0400, rbo...@rcbowen.com wrote:
> So, I'm working through this list: 
> https://boxofclue.com/doap_projects.txt by sending each project a
> reminder of the process, and the reasons it matters (See
> https://hackmd.io/AtAuQ60JRbWcH8-OsCHccQ for my template). I am not
> planning to do all of these at once, so if someone else wanted to
> pick
> up at some other point in the list and work through, that would be
> fine
> - just report back so we don't gang up on any PMC.

Ok, I've notified every PMC on this list (with two exceptions) that
they're missing a DOAP file, and I'll follow up on this in a week or
so.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: RFC: many PMCs have not provided DOAPs

[rbowen]

On Tue, 2023-09-05 at 09:55 -0400, Gary Gregory wrote:
> > https://boxofclue.com/doap_projects.txt by sending each project a
> 
> Eat own dog food ;-) https://paste.apache.org/

Just to be clear ... are you volunteering to help with this outreach?

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Missing projects in https://projects.apache.org/create.html

[rbowen]

On Tue, 2023-09-05 at 09:45 -0400, rbo...@rcbowen.com wrote:
> It looks like there's a number of projects missing from the "create"
> form on projects.apache.org

Ok, they're all there now. If someone feels that we should remove the
attic'ed projects from that list, please go right ahead and do that.

> 
> It looks like every project has a file in
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees
> but that they haven't all been added to the project dropdown on
> https://projects.apache.org/create.html
> 
> I'm working on this, but it's going to take me a while, and I am sure
> I
> could use another pair of eyes to verify that I haven't missed
> anything.
> 
> FYI, there's instructions on how to add a new TLP at
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/READM
> E_NEWTLP but it appears that (possibly for several years?) someone
> has
> been doing part of it, but not updating the create.html file.
> 
> This is something that any ComDev committer can do, if you have time
> and are inclined. And any enhancements to the data we have on our
> projects makes it a little easier for beginners to find out about
> projects and get involved.
> 
> Thanks for any help I can get here.
> 
> --Rich


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Missing projects in https://projects.apache.org/create.html

[rbowen]

It looks like there's a number of projects missing from the "create"
form on projects.apache.org

It looks like every project has a file in
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees
but that they haven't all been added to the project dropdown on
https://projects.apache.org/create.html

I'm working on this, but it's going to take me a while, and I am sure I
could use another pair of eyes to verify that I haven't missed
anything.

FYI, there's instructions on how to add a new TLP at
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/READM
E_NEWTLP but it appears that (possibly for several years?) someone has
been doing part of it, but not updating the create.html file.

This is something that any ComDev committer can do, if you have time
and are inclined. And any enhancements to the data we have on our
projects makes it a little easier for beginners to find out about
projects and get involved.

Thanks for any help I can get here.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: RFC: many PMCs have not provided DOAPs

[rbowen]

Hey, ComDev folks,

Sebb sent the below to board@ earlier today, and I took it upon myself
to ping some of these projects, in the hopes that we can get better
data about our projects.

It's bugged me for a while how many of our projects have meaningless
descriptions, and it's been on my list for a long time to go around and
encourage/help these projects to write better descriptions, so that
beginners can have some notion of what they are looking at.

Sebb's email looks like a really great place to start.

So, I'm working through this list: 
https://boxofclue.com/doap_projects.txt by sending each project a
reminder of the process, and the reasons it matters (See
https://hackmd.io/AtAuQ60JRbWcH8-OsCHccQ for my template). I am not
planning to do all of these at once, so if someone else wanted to pick
up at some other point in the list and work through, that would be fine
- just report back so we don't gang up on any PMC.

*Hopefuly* we'll either start seeing some new DOAP files, or we'll see
some feedback here on this list about problems encountered.

Thanks, again, Sebb, for your attention to detail.

--Rich


On Tue, 2023-09-05 at 00:19 +0100, sebb wrote:
> I've done a check of the PMCs that have no active DOAPs, as listed by
> projects.apache.org.
> 
> There are 59 of them [1], which is about 28% of the total.
> 
> That means a lot of ASF PMCs are not fully represented in the project
> listings.
> 
> The DOAPs provide various useful data about ASF projects, and the
> project listings may help PMCs attract contributors who are looking
> for a project to support, so it is a shame that a large proportion of
> PMCs are not represented.
> 
> Maybe it would be a good idea to remind these PMCs that DOAPs can be
> helpful to the health of their project?
> 
> There is a guide [2] for creating DOAPs.
> 
> Sebb
> [1] Search the page
> https://projects.apache.org/projects.html?committee for the string
> '(0)'
> [2] https://projects.apache.org/create.html


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Please add Pulsar Summit to the Events calendar

[rbowen]

On Wed, 2023-08-30 at 22:30 +0800, tison wrote:
> Thank you!
> 
> I saw an entry for Pulsar Summit APAC at 2023-11-17 to 2023-11-18.
> But it
> isn't planned on the pulsar-summit site and I don't hear of it. Do
> you know
> when and who add this entry?

I don't, although it was either me or Mark Thomas. I've removed it.
Please let me know if we need to add anything back.

--Rich

>  于2023年8月30日周三 21:55写道：
> 
> > On Wed, 2023-08-30 at 09:25 +0800, tison wrote:
> > > Hi,
> > > 
> > > Please add Pulsar Summit to the Apache Events calendar[1]. It has
> > > trademarks approval[2].
> > > 
> > > Pulsar Summit – October 25-27, 2023
> > > https://pulsar-summit.org/event/north-america-2023
> > > San Francisco
> > > 
> > > Best,
> > > tison.
> > > 
> > > [1] https://events.apache.org/event/calendar.html
> > > [2]
> > > https://lists.apache.org/thread/hwyy82xbrv6qm6dnssc5dmy1f8n4o7dt
> > 
> > Done.
> > 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Please add Pulsar Summit to the Events calendar

[rbowen]

On Wed, 2023-08-30 at 09:25 +0800, tison wrote:
> Hi,
> 
> Please add Pulsar Summit to the Apache Events calendar[1]. It has
> trademarks approval[2].
> 
> Pulsar Summit – October 25-27, 2023
> https://pulsar-summit.org/event/north-america-2023
> San Francisco
> 
> Best,
> tison.
> 
> [1] https://events.apache.org/event/calendar.html
> [2] https://lists.apache.org/thread/hwyy82xbrv6qm6dnssc5dmy1f8n4o7dt

Done.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Please add Cassandra Summit to the Events calendar

[rbowen]

On Tue, 2023-08-29 at 20:37 +0200, Mick Semb Wever wrote:
> Please add Cassandra Summit to the Apache Events calendar¹. It has
> trademarks approval².  This might be an update, as the dates got
> changed.
> 
> Cassandra Summit – December 12-13, 2023
> https://events.linuxfoundation.org/cassandra-summit/
> San Jose McEnery Convention Center, California

Done. And hoping to be there!

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: AW: [DRAFT] Email to all PMCs or Committers

[rbowen]

On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> Hi all,
> 
> So, I think we should stay with Rich’s version of the email.
> Now to the next question … which list should we post this to?

I think this should go to all dev@ lists, as those are the people
affected.

> And what do you think should we define as a date when we’ll switch?
> As far as I understood things, Infa merges PRs like mine on
> Thursdays.
> How much time to we want to give people to adjust their .asf.yml?
> 
> Do 4 weeks make sense, or would a shorter time be better?
> (I mean … we all know that it really doesn’t matter if you give
> people a week or a year … they’ll always be surprised)
> 
> The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t
> really think we should go beyond that.
> 
> What do you think?

4 weeks/30 days makes the most sense to me.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Short Email to committers@ highlighting our generative AI/tools guidance

[rbowen]

On Fri, 2023-08-04 at 19:01 +0300, Roman Shaposhnik wrote:
> On Fri, Aug 4, 2023 at 3:53 PM  wrote:
> > 
> > On Fri, 2023-08-04 at 15:26 +0300, Roman Shaposhnik wrote:
> > > Hi!
> > > 
> > > I was contemplating sending a really short email
> > > to committers@ with the $subj. Who should I talk
> > > with to get this done (or convince myself that
> > > an email to a different ML is better ;-))?
> > 
> > 
> > It's definitely hard to know what ML is correct. committers@ does
> > indeed go to the correct audience, but we have trained people to
> > ignore
> > that list for many years.
> 
> Yeah... thinking I'll probably CC members@ ?

Yeah, probably. Or possibly the project dev lists?

> 
> > Please *also* post the policy/advice/guidance/whatever it is to a
> > web
> > page on either community.apache.org/contributors or somewhere on
> > apache.org for permanent reference.
> 
> https://news.apache.org/foundation/entry/asf-legal-committee-issues-generative-ai-guidance-to-contributors
> 
> and
> 
> https://www.apache.org/legal/generative-tooling.html


Oh, right, that. :) I thought this might be something new. Cool.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [POLL] Should we ask Infra to change the defaults used to generate GitHub integration email subjecs?

[rbowen]

On Fri, 2023-08-04 at 06:46 -0700, Craig Russell wrote:
> I agree with Mark.
> 
> > On Aug 4, 2023, at 02:36, Mark Thomas  wrote:
> > 
> > I suggest the following:
> > 
> > - announce to projects that the default is changing in X days /
> > weeks
> >  (or even months) time
> > - provide instructions for what projects need to do before then to
> > keep
> >  the existing format
> 
> Include in the message the actual current defaults that can be
> copy/pasted into the projects' asf.yaml for project who prefer the
> current state.
> 

The longer the email is, the less chance that the target audience will
read it. Please see my updated draft, which links to the "keep your
terrible defaults" page.

I'm also working on updating the phrasing of that page to make it, too,
less about "here's what's broken" and more about "Here's how you can
tweak the defaults", at least until the change is made. At that point,
we'll have a "classic configuration" snippet there for people who
really, actually, for some inscrutable reason, want the current
setting.

But the current setting is objectively awful, and so far I have not
heard even one person saying that it's better. I'm perplexed as to why
we'd want to even suggest, much less encourage, remaining with the
current setting.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [DRAFT] Email to all PMCs or Committers

[rbowen]

On Fri, 2023-08-04 at 15:26 +0200, Jarek Potiuk wrote:
> +1. Looks way better.

Updated draft, for the sake of having it in the archive:



Subject: Mailing list threading improvements
Dear {Committers/members of the Apache PMCs},

TL;DR: We’re updating how auto-generated email from Github will be
threaded on your mailing lists. If you want to keep the old defaults,
details are below.

We’re pleased to let you know that we’re tweaking the way that auto-
generated email from Github will appear on your mailing lists. This
will lead to more human-readable subject lines, and the ability of most
modern mail clients to correctly thread discussions originating on
Github.

Background: Many project mailing lists receive email auto-generated by
Github. The way that the subject lines are crafted leads to messages
from the same topic not being threaded together by most mail clients.
We’re fixing that.

The way that these messages are threaded is defined by a file -
.asf.yml - in your git repositories. We’re changing the way that it
will work by default if you don’t choose settings. If you’re happy for
us to make this change, don’t do anything - the change will happen on
{DATE}.

Details of the current default, as well as the proposed changes, are on
the following page, along with instructions on how to keep your current
settings, if you prefer:

https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

Please copy dev@community.apache.org on any feedback.

Chris, on behalf of the Comdev PMC

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Short Email to committers@ highlighting our generative AI/tools guidance

[rbowen]

On Fri, 2023-08-04 at 15:26 +0300, Roman Shaposhnik wrote:
> Hi!
> 
> I was contemplating sending a really short email
> to committers@ with the $subj. Who should I talk
> with to get this done (or convince myself that
> an email to a different ML is better ;-))?


It's definitely hard to know what ML is correct. committers@ does
indeed go to the correct audience, but we have trained people to ignore
that list for many years.

Please *also* post the policy/advice/guidance/whatever it is to a web
page on either community.apache.org/contributors or somewhere on
apache.org for permanent reference.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [DRAFT] Email to all PMCs or Committers

[rbowen]

On Fri, 2023-08-04 at 08:45 -0400, rbo...@rcbowen.com wrote:
> Ok, I propose this alternative approach - more on the "here's how
> things are getting better" tone than the "Here's how things were
> awful"
> tone, and half the length:

Note: Draft lives here: https://hackmd.io/OLN1OC9UTIuk5seu5S8ZcQ - and
I've made a few small corrections/tweaks.

> 
> 
> 
> 
> Subject: Mailing list threading improvements
> To: dev@
> 
> Dear Apache project developers,
> 
> TL;DR: We’re updating how auto-generated email from Github will be
> threaded on your mailing lists. If you want to keep the old defaults,
> details are below.
> 
> We’re pleased to let you know that we’re tweaking the way that auto-
> generated email from Github will appear on your mailing lists. This
> will lead to more human-readable subject lines, and the ability of
> most
> modern mail clients to correctly thread discussions originating on
> Github.
> 
> Background: Many project lists receive email auto-generated on
> Github.
> The way that the subject lines are crafted leads to messages from the
> same topic not being threaded together by most mail clients. We’re
> fixing that.
> 
> The way that these messages are threaded is defined by a file -
> .asf.yml - in your git repositories. We’re changing the way that it
> will work by default if you don’t choose settings. The change will
> happen on {DATE}
> 
> Details of the current default, as well as the proposed changes, are
> on
> this page, along with instructions on how to keep your current
> settings, if you prefer:
> 
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> 
> Chris, on behalf of the Comdev PMC
> 
> 
> 
> 
> 
> 
> On Fri, 2023-08-04 at 07:30 -0400, Rich Bowen wrote:
> > As discussed offline, I feel like the tone of this messaging is
> > wrong. Give me a bit to get to my desk and I will propose an
> > alternate draft.
> > 
> > Shosholoza, 
> > Rich
> >     
> > 
> > On Fri, Aug 4, 2023, 04:43 Christofer Dutz
> >  wrote:
> > > Hi,
> > > 
> > > Here comes a draft for an email I would like to send out.
> > > 
> > > Not quite sure which audience we should choose … committers,
> > > (p)pmcs?
> > > 
> > > Also, not quite sure about the timeframe? As I know Infra merges
> > > PRs on Thursdays, I would propose the 17th of August 2023 as date
> > > for the change to be made. This would give project almost 2 weeks
> > > to react and adjust their .asf.yml files, if they wish to stay at
> > > the current defaults.
> > > 
> > > So, I wasn’t sure, if I should add links to examples, as it would
> > > be putting the project acting as negative example in an
> > > unfortunate
> > > spotlight and using date ranges in ponymail links has been not
> > > quite successful in the past.
> > > 
> > > What do you folks think?
> > > 
> > > 
> > > Chris
> > > 
> > > 
> > > --
> > > 
> > > 
> > > Dear {Committers/members of the Apache PMCs},
> > > 
> > > over the years have we added additional options for discussing
> > > project matters on a big variety of alternate locations and
> > > systems
> > > besides email lists, such as JIRA and GitHub.
> > > Especially GitHub has been growing in acceptance, as it generally
> > > allows participating without requiring yet another login.
> > > 
> > > GitHub currently allows discussing things using: GitHub Issues,
> > > GitHub PRs and GitHub Discussions.
> > > Infra has built tooling, that forwards these discussions to our
> > > mailing-lists.
> > > 
> > > Unfortunately, some defaults were chosen, which have resulted in
> > > many dev-lists being swamped with emails, for which no email-
> > > client
> > > was able to implement any form of threading.
> > > Some projects simply reacted by redirecting these emails to
> > > lists,
> > > such as notifications@ or commits@.
> > > Some projects even completely gave up communicating via email
> > > lists
> > > and only “come back” for voting.
> > > Even if the requirement “If it didn’t happen on the list, it
> > > didn’t
> > > happen” sort of is fulfilled, it no longer fulfills what the core
> > > of this rule was:
> > > To allow someone to asynchronously participate and find out
> > > what’s
> > > happening in a project without requiring any form of login and to
> > > have some sort of archive of all discussions about Apache
> > > projects
> > > on Apache hardware.
> > > 
> > > In Comdev we have been discussing how we could possibly address
> > > this and bring back the usefulness of our mailing-lists.
> > > The tooling Infra provides us with, already allows individual
> > > projects to change the settings of the auto-generated emails and
> > > several projects have already done so, with great success.
> > > 
> > > Comdev has therefore proposed to change the default settings for
> > > auto-generated emails sent out for GitHub.
> > > These changes will not change anything for projects hat already
> > > manage how the emails should be formatted in

Re: [DRAFT] Email to all PMCs or Committers

[rbowen]

Ok, I propose this alternative approach - more on the "here's how
things are getting better" tone than the "Here's how things were awful"
tone, and half the length:




Subject: Mailing list threading improvements
To: dev@

Dear Apache project developers,

TL;DR: We’re updating how auto-generated email from Github will be
threaded on your mailing lists. If you want to keep the old defaults,
details are below.

We’re pleased to let you know that we’re tweaking the way that auto-
generated email from Github will appear on your mailing lists. This
will lead to more human-readable subject lines, and the ability of most
modern mail clients to correctly thread discussions originating on
Github.

Background: Many project lists receive email auto-generated on Github.
The way that the subject lines are crafted leads to messages from the
same topic not being threaded together by most mail clients. We’re
fixing that.

The way that these messages are threaded is defined by a file -
.asf.yml - in your git repositories. We’re changing the way that it
will work by default if you don’t choose settings. The change will
happen on {DATE}

Details of the current default, as well as the proposed changes, are on
this page, along with instructions on how to keep your current
settings, if you prefer:

https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

Chris, on behalf of the Comdev PMC






On Fri, 2023-08-04 at 07:30 -0400, Rich Bowen wrote:
> As discussed offline, I feel like the tone of this messaging is
> wrong. Give me a bit to get to my desk and I will propose an
> alternate draft.
> 
> Shosholoza, 
> Rich
>     
> 
> On Fri, Aug 4, 2023, 04:43 Christofer Dutz
>  wrote:
> > Hi,
> > 
> > Here comes a draft for an email I would like to send out.
> > 
> > Not quite sure which audience we should choose … committers,
> > (p)pmcs?
> > 
> > Also, not quite sure about the timeframe? As I know Infra merges
> > PRs on Thursdays, I would propose the 17th of August 2023 as date
> > for the change to be made. This would give project almost 2 weeks
> > to react and adjust their .asf.yml files, if they wish to stay at
> > the current defaults.
> > 
> > So, I wasn’t sure, if I should add links to examples, as it would
> > be putting the project acting as negative example in an unfortunate
> > spotlight and using date ranges in ponymail links has been not
> > quite successful in the past.
> > 
> > What do you folks think?
> > 
> > 
> > Chris
> > 
> > 
> > --
> > 
> > 
> > Dear {Committers/members of the Apache PMCs},
> > 
> > over the years have we added additional options for discussing
> > project matters on a big variety of alternate locations and systems
> > besides email lists, such as JIRA and GitHub.
> > Especially GitHub has been growing in acceptance, as it generally
> > allows participating without requiring yet another login.
> > 
> > GitHub currently allows discussing things using: GitHub Issues,
> > GitHub PRs and GitHub Discussions.
> > Infra has built tooling, that forwards these discussions to our
> > mailing-lists.
> > 
> > Unfortunately, some defaults were chosen, which have resulted in
> > many dev-lists being swamped with emails, for which no email-client
> > was able to implement any form of threading.
> > Some projects simply reacted by redirecting these emails to lists,
> > such as notifications@ or commits@.
> > Some projects even completely gave up communicating via email lists
> > and only “come back” for voting.
> > Even if the requirement “If it didn’t happen on the list, it didn’t
> > happen” sort of is fulfilled, it no longer fulfills what the core
> > of this rule was:
> > To allow someone to asynchronously participate and find out what’s
> > happening in a project without requiring any form of login and to
> > have some sort of archive of all discussions about Apache projects
> > on Apache hardware.
> > 
> > In Comdev we have been discussing how we could possibly address
> > this and bring back the usefulness of our mailing-lists.
> > The tooling Infra provides us with, already allows individual
> > projects to change the settings of the auto-generated emails and
> > several projects have already done so, with great success.
> > 
> > Comdev has therefore proposed to change the default settings for
> > auto-generated emails sent out for GitHub.
> > These changes will not change anything for projects hat already
> > manage how the emails should be formatted in their .asf.yml files,
> > but it will affect all projects, that didn’t explicitly do that.
> > 
> > For all projects willing to stay at the current format, we
> > encourage to have a look at this page and prepare their “.asf.yml”
> > files accordingly:
> > https://community.apache.org/contributors/mailing-lists.html
> > (This page currently lists the current defaults here
> > https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-t

Re: [POLL] Should we ask Infra to change the defaults used to generate GitHub integration email subjecs?

[rbowen]

+1 to making this change. It would immediately make our mailing lists
more consumable and welcoming to actual humans.

Coupled with a page explaining how this works (Oh! Look! There's
already one at
https://community.apache.org/contributors/mailing-lists.html ) this
would be a great service to our communities.



On Tue, 2023-08-01 at 12:16 +, Christofer Dutz wrote:
> Starting a new thread as the last one sort of dried up and didn’t
> quite form anything actionable.
> 
> Being subscribed to many of our mailing-lists and most recently
> looking into every project, dev-lists when reviewing board reports, I
> have seen many of our lists literally being rendered useless.
> 
> Useless, because it’s almost impossible to follow these lists, as a
> large percentage of the emails are:
> 
>   *   Generated emails and the way they are currently generated makes
> it impossible for email clients to correctly display them as threads.
>   *   Contain so much redundant information, that the actual start of
> the header that I’m interested in reading is usually not readable on
> mobile phones.
>   *   Most discussions have been moved away from the lists
> (notifications@, commits@), having left over only skeletons in which
> every now and then a vote is being handled.
> 
> My proposal is to change the default settings for auto-generated
> GitHub emails for all projects (not just the new ones) to be a much
> more condensed version.
> 
> With these changes, all existing lists, that haven’t manually
> configured the format of the emails, instantly get readable lists
> again.
> 
> Some would argue that there might be projects that could object these
> changes, but I would on the other hand bet that more projects would
> be in favor of such a change than not.
> Those who don’t want a change, can simply go back to the old format,
> by specifying it in one commit for which we can even provide a
> default .asf.yaml snippet.
> 
> Some people expressed the wish to have longer prefixes, such as
> “[ISSUE]”, “[PULL-REQUEST]” or “[DISCUSSION]” however do these not
> add much information to the email that “[I]”, “[PR]” and “[D]” don’t
> and the shorter version allows displaying more of the subject on
> mobile email clients.
> 
> Here’s an example of a project list before the changes:
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
> Here’s an example of the same list after using the other defaults:
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18
> 
> Here’s an example on how even ponymail is now able to display
> something happening on GitHub as a discussion you can also follow
> nicely via email:
> https://lists.apache.org/thread/rnr9tjx9rsnqc7b5nwcf68qnp5bkr9hc
> 
> I would propose to keep the repository as part of the templates, even
> if since my PR last week was merged it’s now possible to omit that
> too.
> 
> I care deeply about our projects, and I would really hate to see our
> core principles being lost more and more (“If it didn’t happen on the
> list, it didn’t happen”).
> 
> You would make me really happy if I could get some general approval
> by you folks here.
> 
> 
> Chris
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Setting up Git Project under comdev for Community Over Code EU

[rbowen]

On Mon, 2023-07-31 at 17:40 +0200, Jarek Potiuk wrote:
> Hmm,
> 
> Is it possible to create a repo there then (apachecon-eu - until we
> rename the group) - I tried to create one with boxer -
> https://gitbox.apache.org/boxer/?action=newrepo but it's greyed-out.
> 
> Or I guess I need more karma for that one?


Nope, it's greyed out for me too. I would suggest opening an infra
ticket.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Setting up Git Project under comdev for Community Over Code EU

[rbowen]

On Mon, 2023-07-31 at 15:51 +0200, Jarek Potiuk wrote:
> Following up with that after short holidays - how can I (and others
> from the Community over Code EU) get added to the "apachecon" group
> so
> that I can create the repository and have "committer" access to it?
> 
> Do I need a JIRA ticket or just karma granted by someone ? I can
> provide a list of ASF members to add there as a good start.
> 



You are in fact already in that group.

https://whimsy.apache.org/roster/group/apachecon?type=LDAP%20Auth%20Group



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Changing the defaults for GitHub generated email titles?

[rbowen]

On Thu, 2023-07-27 at 16:11 -0400, Kelly Oglesbee wrote:
> exactly what emails are you changing, because I'm experiencing
> problems
> with my emails on my device?

Can you elaborate? What problems are you experiencing? How can the
situation be improved?


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: AW: Changing the defaults for GitHub generated email titles?

[rbowen]

On Thu, 2023-07-27 at 19:46 +, Christofer Dutz wrote:
> Ok,
> 
> so after the discussion didn’t come up with any objections. I
> prepared a PR and that was merged today.
> Now the templates no longer have to have a mandatory “repository”
> variable ;-)
> 
> I updated the PLC4X settings and it seems to be working nicely.
> 
> So … where are we on this discussion?
> I would still like to change the defaults to the patterns I suggested
> (including the repository).
> 
> What’s your thoughts? Should I simply start a vote?

Who's voting? That is, who has the authority to make this change? Yes,
I'm in favor of such a change, but surely Infra are the folks that have
the actual reins here, right?

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: AW: Changing the defaults for GitHub generated email titles?

[rbowen]

On Fri, 2023-06-30 at 13:55 +, Christofer Dutz wrote:
>   *   About breaking automation projects might have set up: I would
> absolutely doubt there is even a single Apache project that has setup
> automation based on these emails. I could imagine that there is a
> hand full of companies paying attention to them, but in this case, I
> would suggest optimizing for community and not these companies.

Yes, we absolutely should prioritize our own project communities over
companies. I didn't realize that we were concerned about *companies*
doing this. They can update their tooling.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Booth opportunity at All Things Open 2023 conference

[rbowen]

On Wed, 2023-06-14 at 19:36 +, Sharan Foga wrote:
> Hi Swapnil
> 
> I'm planning to be there - and could help out. I wont be able to do
> it full time as I might have a talk and other commitments at the
> event. Apart from that I'd be happy to volunteer to do some time on
> the booth.
> 

Me too. (Exactly what Sharan said.)

> On 2023/06/12 18:05:05 Swapnil M Mane wrote:
> > Hello All,
> > Couple of months ago I enquired for having a booth at All Things
> > Open (
> > https://www.allthingsopen.org/). We got a response today and we
> > have an
> > opportunity to have a booth as community partner.
> > 
> > This conference is scheduled from 15-17 October 2023 at
> > Downtown Raleigh, NC USA | Raleigh Convention Center
> > 
> > If you are interested and have availablity to support and manage
> > booth at
> > event please let us know.
> > Based on response from interested volunteers, we will take the next
> > steps.
> > 
> > Best Regards,
> > Swapnil M Mane
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Proposal: Consolidate the various pages about voting/deciding

[rbowen]

We have four pages that discuss decision making, voting, consensus, and
so on.

https://community.apache.org/committers/consensusBuilding.html

https://community.apache.org/committers/lazyConsensus.html

https://community.apache.org/committers/decisionMaking.html

https://community.apache.org/committers/voting.html


I could possibly see this being either one page, or two (with the first
three being one, and then voting being another?) but having four, with
largely overlapping content, is confusing.

I'd like to consolidate, but would like to hear opinions as to whether
this is one page or two (or some other answer) before I get started.

Still working on the last proposal, FYI, so this is still a ways out.
Or, maybe someone else can tackle it?

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [GitHub] [comdev-site] rbowen opened a new pull request, #115: Advice around adding new committers.

[rbowen]

On Mon, 2023-05-15 at 15:33 -0300, Andrew Wetmore wrote:
> Hi, Rich.
> 
> I was afk so was slow to review your pull request. I wanted to
> suggest some
> minor changes, but by the time I submitted my comments the pull
> request had
> happened.
> 
> My comments were:
> 
> line 7: "The addition of new committers" -- "new" is not necessary

Ok. I suppose I could see that.

> line 17: "inviting a new committer" -- "new" is not necessary

The whole emphasis of this doc is new, not existing, committers.
Inviting a committer implies, to me, an existing one, and I think "new"
clarifies here, even if it is not strictly necessary.

> line 34: "committers that" should be "committers who"
> line 49: I think "whims" should be "whim"
> line 50: "someone that" should be "someone who"
> line 74: need a comma after the link and before "which"
> lines 77-78: "that a committers" should be either "that a committer"
> or
> "that committers"

All changes made. Thanks.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Proposal: Consolidate redundant beginner pages

[rbowen]

We have four beginner/getting started pages, with redundant
information:

https://community.apache.org/contributors/
https://community.apache.org/newcomers/
https://community.apache.org/gettingStarted/101.html
https://community.apache.org/newbiefaq.html

The 'gettingStarted' directory is otherwise empty. It's also our only
camelCaps directory. The content in the 101.html page is kinda for new
contributors, with a little "finding your way around" thrown in.

/newcomers/ is almost entirely links to other places. And, here too,
there's just that one file in that directory.

Proposal:

/newcomers is for people new to the foundation, trying to figure out
what it's all about. /gettingStarted/101.html will redirect there, and
the content from these three pages that's geared to that audience will
live at /newcomers . This is good for press, users, and others who want
to know their way around, but haven't moved to actual contributions
yet. The /gettingStarted/ directory will go away. 

Content that is for people who are actually trying to *contribute* to a
project will go to the /contributors page.

The unfortunately named newbiefaq contains content in both of the above
categories. I propose splitting it between those two categories as
appropriate, and then redirecting /newbiefaq.html to /newcomers

Unless there are objections, that's what I'll be working on next.

Thoughts/advice/objections solicited.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [website] FYI, tag-based navigation added to community.a.o

[rbowen]

On Thu, 2023-04-27 at 12:40 +0100, sebb wrote:
> Now all we need is one of those electronic devices to find the tags
> index ...

Can you please elaborate on what this means?


> 
> On Thu, 27 Apr 2023 at 11:17, Roy Lenferink 
> wrote:
> > 
> > I just had a look and I definitely like this addition.
> > 
> > Thanks for adding this!
> > 
> > Roy
> > 
> > Op do 27 apr 2023 om 11:24 schreef Bertrand Delacretaz <
> > bdelacre...@apache.org>:
> > 
> > > Hi,
> > > 
> > > I meant to activate this in a preview branch first, but that
> > > didn't
> > > work as Hugo generates absolute URLs for the tag navigation.
> > > 
> > > So I have committed my tag-based navigation changes to our
> > > website,
> > > you can start at https://community.apache.org/tags.html to see
> > > how it
> > > looks.
> > > 
> > > Feedback is welcome, and if this broke anything it's easy to
> > > revert!
> > > 
> > > I have added an initial set of tags to some pages [1], feel free
> > > to
> > > add more, trying to reuse existing tags as much as possible.
> > > 
> > > I'm a big fan of tag-based navigation, as menu-based usually only
> > > fits
> > > a single mental model, with tags it's much easier to discover
> > > related
> > > content.
> > > 
> > > -Bertrand
> > > 
> > > [1]
> > > https://github.com/apache/comdev-site/commit/3bb0a6382cda77f31d211e82eac5270f73d58906
> > > 
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > > 
> > > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Best Practice documentation

[rbowen]

On Thu, 2023-04-20 at 15:43 +0200, Bertrand Delacretaz wrote:
> Hi Rich,
> 
>  wrote:
> > ...I appreciate your consideration. I know it's a big patch
> 
> Note that you can commit to a comdev-site branch named
> preview/ to get a staged preview, which might be easier
> for
> people to review.
> 
> The https://github.com/apache/comdev-site/tree/preview/test2-staging
> branch for example is staged at
> https://community-test2.staged.apache.org/


Could you possibly explain to me specifically how to do this? My Git-fu
is failing me.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [GitHub] [comdev-site] bdelacretaz commented on pull request #102: Best practice docs for PMCs, etc

[rbowen]

On Thu, 2023-04-20 at 13:17 +, bdelacretaz (via GitHub) wrote:
> 
> bdelacretaz commented on PR #102:
> URL:
> https://github.com/apache/comdev-site/pull/102#issuecomment-1516313840
> 
>    This looks really nice and useful, thanks!
>    
>    I see at least two existing pages that overlap with this new
> content:
>    
>    * https://apache.org/foundation/how-it-works.html

Yes, the how-it-works page is useful, but very terse, and tries to cram
everything into one page, rather than segregating by audience, as I'm
trying to do. Both are useful, but I think they should like to each
other.


>    * https://community.apache.org/contributors/

That page is very muddled, and I have plans to un-muddle it. I think it
tries to cover too much in one page, and also addresses several
audiences at the same time.

>    
>    The first one might just need a link to this new content, which is
> less formal and more detailed. And also the reverse link, maybe a
> "See Also" section in your contributors ladder page?
>    
>    The second one might be replaced by your new content? In which
> case I'd suggest
> [redirecting](https://github.com/apache/comdev-site/blob/main/static/
> .htaccess), so that the old URL remains valid.


My intent is that /contributors/, /committers/, and /pmc/ would each
have an index page that outlines what topics are covered in that
directory. I don't want to lose the content that is currently on
/contributors/index but I think that it might end up going other
places.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Best Practice documentation

[rbowen]

TL;DR: https://github.com/apache/comdev-site/pull/102

I've been wanting, for *years*, to write more best practice
documentation for the various segments of our community.

Recently I attended a talk about the "contributor ladder" - a concept
used in CNCF communities. This is where you describe each rung of your
climb through a community, with particular focus on:

* The attributes of that rung (responsibilities, best practice, and
detailed howtos)
* How to get to the next rung

Communicating to people how to progress up the ladder is critical to
keeping people engaged. This is much like knowing what your potential
promotion path is at a job, and how to improve your chances of
promotion. People want to understand whether it's possible to become
more involved and influential in a community, and how to go about it.

This includes stuff like:

* What's the bar to becoming a committer?

(Note this is useful not only to the contributor, but it's important
that the PMC has thought about this, and it's not either completely
arbitrary, or overly benefiting one class of people, such as by
employer, geography, or peer group.)

* What's the criteria for a committer becoming a PMC member?

(Some projects grant both at the same time, always. Others make you
slog through hot lava for 3 years. What's important is that the PMC
members know what the criteria are, and they're not arbitrary or unduly
benefiting one class of people.)

* What responsibilities are associated with being a PMC member?

* How are decisions made in your project, and by whom? How can I become
one of those people.


We have, for a long time, relied on the Incubator to educate our
communities. That's great, for the people who were there at the time.
We need to do a better job of continuing education of the people that
come to the project later on, or who have forgotten.

ComDev is, IMHO, the place to do that. It's literally Community
Development.

This PR is a small part of how I see this working. I appreciate your
consideration. I know it's a bit patch. You can see the skeleton of it
here:

Contributor ladder:
https://github.com/rbowen/comdev-site/blob/pmc-docs/source/contributor-ladder.md

PMC best practices:
https://github.com/rbowen/comdev-site/blob/pmc-docs/source/pmc/_index.md


--Rich



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Broken link in GSoC article on news.a.o

[rbowen]

On Wed, 2023-03-29 at 15:56 +0100, sebb wrote:
> On Wed, 29 Mar 2023 at 15:42, Roy Lenferink 
> wrote:
> > 
> > I just noticed a broken link in the following blog post:
> > https://news.apache.org/foundation/entry/asf-to-mentor-gsoc-contributors-in-2023
> > 
> > The link "Students: read this!" refers to
> > 
> > https://community.apache.org/gsoc.html#students-read-this
> > 
> > instead of
> > 
> > https://community.apache.org/gsoc/#students-read-this
> > 
> > This probably has to do with refactoring the GSoC sections.
> 
> I think it is more likely due to the __index.md renames.
> 
> > Does anyone know who wrote that blog post and how to correct the
> > broken
> > link?
> 
> There should be no need to correct the blog post.
> 
> Indeed unless that link never worked, I don't think that is the
> correct way to fix a broken link, as it will only fix that instance
> of
> the link.
> There may be many others.
> 
> It should be possible to redirect to the updated page using .htaccess
> (I'll try and fix that shortly).


The link did work until last week, when all gsoc content was moved into
a gsoc subdir.



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: comdev-website: why are files named __index.md rather than _index.md?

[rbowen]

On Sun, 2023-03-26 at 16:12 +0100, sebb wrote:
> Most of the index files are named __index.md, except for one which is
> _index.md.
> 
> Why is this?
> 
> Do they serve a different purpose?

Yeah, I wondered this, too, but just stick with the convention. I'd
like to understand this. Roy, can you give some insight here please?

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Offer for help

[rbowen]

On Thu, 2023-03-23 at 16:34 -0400, Chris Wells wrote:
> Greetings,
> 
> When I rebooted one of your VMs a couple weeks ago I recognized that
> ComDev might appreciate some volunteer time to help with things like
> VM management, tooling maintenance, etc... Member Chris (not as an
> Infra Staffer), would be happy to help out for a couple hours a
> month. Just let me know if you're interested and how I can help out.


I would suggest that most of us don't even know what we need, and would
greatly appreciate such assistance.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: GSoC messaging?

[rbowen]

On Tue, 2023-03-21 at 14:35 +0100, Roy Lenferink wrote:
> Something I have been wondering for a couple of weeks now: does it
> make
> sense to
> keep the current name 'mentors@community' for the GSoC mentors
> mailing list
> ?
> 
> Maybe it is possible to rename the mentors@community mailing list to
> something
> like gsoc-mentors@community to prevent confusion that we have an
> active
> mentors program.

While I might agree, it seems it would be less disruptive to do this
between GSoC's, rather than while one is currently in-flight.


> 
> And maybe also introduce a new list, e.g. gsoc@community for all GSoC
> stuff
> (the JIRA notifications can also be send there). I feel like all the
> GSoC
> notifications are a bit
> much for the dev@community list.
> 
> Op di 21 mrt 2023 om 14:27 schreef :
> 
> > On Tue, 2023-03-21 at 10:28 +0700, Maxim Solodovnik wrote:
> > > Done:
> > > 
> > https://github.com/apache/comdev-site/commit/4d4fb12609f3b3ef62e398acac4282798ddafcc0
> > > Sorry for delay :)
> > > 
> > > New JIRA GSOC project was created (Thanks to sebb)
> > > So I'll try to update all docs, move current JIRAs and notify
> > > mentors@
> > > list as my next steps :))
> > 
> > This is fantastic. Thanks.
> > 
> > --Rich
> > 
> > 
> > > 
> > > 
> > > On Thu, 16 Mar 2023 at 23:55,  wrote:
> > > > 
> > > > On Thu, 2023-03-16 at 23:24 +0700, Maxim Solodovnik wrote:
> > > > > Hello Rich,
> > > > > 
> > > > > we are using mentors@community.a.o ML for communications
> > > > > 
> > > > > I'll try to keep https://community.apache.org/gsoc.html page
> > > > > in
> > > > > up-to-date state :)
> > > > > 
> > > > > I'll move all GSoC related pages (there should be 3-5 of
> > > > > them) to
> > > > > subfolder (will try to do it before Monday)
> > > > > 
> > > > > And will update this thread :)
> > > > 
> > > > Thank you. That's awesome.
> > > > 
> > > > There's a lot of ambiguity, on the website, between GSoC and
> > > > Mentoring,
> > > > and getting the GSoC stuff into a subdir would greatly help
> > > > with
> > > > that.
> > > > 
> > > > --Rich
> > > > 
> > > > ---
> > > > 
> > > > --
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > 
> > > 
> > > 
> > 
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> > 
> > 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: GSoC messaging?

[rbowen]

On Tue, 2023-03-21 at 10:28 +0700, Maxim Solodovnik wrote:
> Done:
> https://github.com/apache/comdev-site/commit/4d4fb12609f3b3ef62e398acac4282798ddafcc0
> Sorry for delay :)
> 
> New JIRA GSOC project was created (Thanks to sebb)
> So I'll try to update all docs, move current JIRAs and notify
> mentors@
> list as my next steps :))

This is fantastic. Thanks.

--Rich


> 
> 
> On Thu, 16 Mar 2023 at 23:55,  wrote:
> > 
> > On Thu, 2023-03-16 at 23:24 +0700, Maxim Solodovnik wrote:
> > > Hello Rich,
> > > 
> > > we are using mentors@community.a.o ML for communications
> > > 
> > > I'll try to keep https://community.apache.org/gsoc.html page in
> > > up-to-date state :)
> > > 
> > > I'll move all GSoC related pages (there should be 3-5 of them) to
> > > subfolder (will try to do it before Monday)
> > > 
> > > And will update this thread :)
> > 
> > Thank you. That's awesome.
> > 
> > There's a lot of ambiguity, on the website, between GSoC and
> > Mentoring,
> > and getting the GSoC stuff into a subdir would greatly help with
> > that.
> > 
> > --Rich
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> > 
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: dev Digest 17 Mar 2023 17:32:48 -0000 Issue 2294

[rbowen]

On Fri, 2023-03-17 at 19:14 +, Donavon Gamblin wrote:
> 
> o unsubscribe, e-mail: dev-digest-unsubscr...@community.apache.org
> 
> i need unsubscribed asap

The instructions are in the email that you sent:

> To unsubscribe, e-mail: dev-digest-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-digest-h...@community.apache.org

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: tika-offheap-leak

[rbowen]

Hi.

Unfortunately, you've reached the wrong list. This is a general
community list for the Apache Software Foundation as a whole. Tika has
its own lists, which you can find at
https://tika.apache.org/mail-lists.html and that's where the people
that can help with this hang out.

--Rich

On Fri, 2023-03-17 at 22:02 +0800, 朱桂锋 wrote:
> Firstly,  thank you for tika project, she is great project!
> 
> Recently, i run the tika project and extract text from document， i
> find
> java offheap is increasing until all the memory to the 100%, and then
> killed by oom-killer.
> 
> then i use pmap and dump data from memory(exclude the java heap), i
> find
> they are like this:
> 
> [ Content
> 
> Types] . xM1PK
> 
> rels/.relsPK word/ rels/document.xm1.relsPK word /document.xm1PK
> word/footer4.xmIPK word/header4. xm1PK word/footer2.xmIPK
> word/header2.
> xm1PK word /header3.xmIPK word/footer3.xmlPK word /header1.xm1PK
> 
> word/ footer1 . xm1PK
> 
> word / footnotes.xmlPK word/endnotes .xm1PK word/header5. xm1PK
> word/media/
> image3.pngPK word/media/imagel. jpegPK word/media/image2. jpegPK word
> /
> theme/ theme 1. xm1PK word/settings. xm1PK
> 
> customxml/ itemProps2 .xm1PK
> 
> customXml /item2 . xm1PK docProps /custom. xm1 PK t?92
> customXml/rels/item1.xm1.relsPK customXml/ rels/item2.xm1.relsPK
> customXm1
> /itemProps1.xm1PK
> 
> 
> 
> they are office document text，why they are in offheap?  so i doubt
> when
> parse some special  office  document  it will cause memory leak.
> 
> And sorry  i don't know what the special office document and i  can't
> afford the sample.
> 
> 
> another infomation:  when i debug code on my own mac computer, using
> xlsx
> sample ,
> when it calling tika.detect, it called ZipArchiveInputStream
> constructor
> twice, and the same times calling java.util.zip.Inflater#end();
> but when it calling tika.parseToString,  it called
> ZipArchiveInputStream
> constructor once, but no times calling java.util.zip.Inflater#end();
> 
> Is that caused the offheap memory leak because of the Inflater use
> native
> code?
> 
> Look forward for your reply!  thank you very much!


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Back to basics: What we do @comdev

[rbowen]

On Fri, 2023-03-17 at 08:45 -0400, Jim Jagielski wrote:
> Maybe part of ComDev could be in the matchmaker aspect of connecting
> external people to internal groups. For example, Petri is a sort of
> mentoring program...

I must admit I had not looked at Petri in that light. Does Petri want
us to send individuals to them for one-on-one mentoring? Or is it more,
as I had understood, for a *project* that is looking for advice?

Yeah, we should absolutely link to https://petri.apache.org/ from ...
somewhere. Unsure what that link text should look like, though.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Back to basics: What we do @comdev

[rbowen]

On Fri, 2023-03-17 at 12:56 +, Drew Foulks wrote:
> Additionally, some sort of volunteer mentoring program would also be
> a huge boon to keeping newcomers involved in the larger community.

While I strenuously agree, I also know how much work it is to run an
actual effective mentoring program. I would *LOVE* to see someone step
up to manage this, even as an informal spreadsheet, mailing list, or
whatever.

Questions that come to mind immediately are:

* Who would we be willing to "endorse" as mentors? Is there some kind
of vetting process so that we don't have random folks posing as
representatives of the Foundation?

* What advice would we give those folks? In particular, I don't want to
throw people into the fire with no guardrails, and end up with people
feeling obliged to be a "do my homework" service. In the past, a HUGE
percentage of the people that come asking for mentoring are trying to
do an assignment for class with vague instructions like "Contribute to
an open source project".

* What kind of disclaimers would we need to put on such a program to
protect folks from people who don't get the results they're looking
for?

I'd want to look at some of the other projects/foundations who have
done this successfully, and see what landmines there are that we can
avoid stepping on.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Back to basics: What we do @comdev

[rbowen]

On Fri, 2023-03-17 at 08:48 +, sebb wrote:
> Created GSOC Jira project; hope that's OK
> 
> Note: self-serve hung, but the project appears to have been  created
> OK.
> 
> If agreed, the next stage would be to update the documentation to
> point to the new project, and transfer existing issues.

Yes please, if Max is on board with this.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Website TODO list

[rbowen]

Yes, I know I've been talking a lot today.

Here's what I see as a first cut at a ToDo list for the website:

https://cwiki.apache.org/confluence/display/COMDEV/Website

I appreciate the folks who have, so far, stepped up to say they'll be
part of this effort. I would ask that if you contribute to the above
Wiki page, you are saying that you'll do stuff, not that "someone
should."

Our current website is a reflection of our "someone should (but not
me)" mindset of the past few years, and I'd like to focus on what we
*will* do, not what we think someone might or could some day.

To be clear, that's largely on me. I wrote the
https://community.apache.org/about/ page as a "stuff we could do, if
people showed up to do it", back in 2017. That was a mistake. I'd like
to take it back, and have the website be only things that we *actually
do*, whereas this mailing list is where we talk about what we could,
possibly, do.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: GSoC messaging?

[rbowen]

On Thu, 2023-03-16 at 23:24 +0700, Maxim Solodovnik wrote:
> Hello Rich,
> 
> we are using mentors@community.a.o ML for communications
> 
> I'll try to keep https://community.apache.org/gsoc.html page in
> up-to-date state :)
> 
> I'll move all GSoC related pages (there should be 3-5 of them) to
> subfolder (will try to do it before Monday)
> 
> And will update this thread :)

Thank you. That's awesome.

There's a lot of ambiguity, on the website, between GSoC and Mentoring,
and getting the GSoC stuff into a subdir would greatly help with that.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: GSoC messaging?

[rbowen]

Ok, I see that https://community.apache.org/gsoc has been updated with
some info.

Is there a chance we could move gsoc content into a subdirectory,
rather than having a half-dozen docs in the top level directory?

--Rich

On Thu, 2023-03-16 at 12:04 -0400, rbo...@rcbowen.com wrote:
>  Do we have any kind of messaging around GSoC this year?
> 
> I see this in the February Comdev report:
> 
> ### GSoC
> We have applied for the GSoC 2023 program and are awaiting
> the final update from the GSoC team on February 21, 2023.
> Meanwhile, we will be working on collecting project ideas from
> various
> PMCs.
> 
> And obviously I see the flood if Jira traffic on this list, but do we
> have any public reporting anywhere about what projects are
> participating, and what's being worked on?
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

GSoC messaging?

[rbowen]

 Do we have any kind of messaging around GSoC this year?

I see this in the February Comdev report:

### GSoC
We have applied for the GSoC 2023 program and are awaiting
the final update from the GSoC team on February 21, 2023.
Meanwhile, we will be working on collecting project ideas from various
PMCs.

And obviously I see the flood if Jira traffic on this list, but do we
have any public reporting anywhere about what projects are
participating, and what's being worked on?



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Back to basics: What we do @comdev

[rbowen]

Hi, folks,

I have tried to write this email several times, and keep getting
overwhelmed. Trying again.

Comdev has no focus. Our website is a mess. We have no clear idea of
what we do. I would like to get back to basics, and figure out what it
actually is that we do here, and get rid of the stuff that we don't.

For example: Looking at the website, we claim we have a mentoring
program. This is not true, and I'd like to cull that entire part of the
site. But I don't want to step on people who might actually want to do
that work.

And that's just one example.

A while back (2017) I rather over-optimistically wrote
https://community.apache.org/about/ which was a list of things that I
hoped that we might do some day. That was a mistake, because it makes
promises that nobody is following up on.

I want to get back to our mandate:

Provide a wide array of information, FAQs, and help to newcomers and
existing committers, and maintains a number of helpful tools.

We should be a repository for useful information and best practice for
people at all levels of our community: newcomers; contributors;
committers; pmcs.

The tools that we presumably maintain include:
projects.a.o
reporter.a.o
helpwanted (I think this is EOL, realistically)

We facilitate Apache Local Communities (which does not appear to be
references on the website?)

And we also facilitate GSoC

I would like to refocus our website, and our efforts, around those
things, and drop everything else from our website, until and unless
someone actually steps up to do them.

And, yes, I'm volunteering to do this work, but want to be sure I'm not
taking too much authority in doing so.



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

PR: Remove helpwanted references

[rbowen]

I've opened a PR - https://github.com/apache/comdev-site/pull/87 - to
drop references to the helpwanted tool, since it hasn't really been the
success that we imagined. There's no content in it, and so it's just
frustrating.

Please let me know if there are any objections to merging that. Thanks.

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Discussion] ASF Booth at FOSSASIA 2023

[rbowen]

On Wed, 2023-03-15 at 15:58 +0530, Priya Sharma wrote:
> Thanks for your reply Rich!
> But, unfortunately, we won't be having our booth there due to a lack
> of volunteers.
> 
> I hope you have a fantastic time at the event!

Ok. Well, perhaps I'll see you there anyway.

> 
> On Tue, 28 Feb 2023 at 19:36,  wrote:
> > 
> > On Tue, 2023-02-28 at 18:27 +0530, Priya Sharma wrote:
> > > Hello All,
> > > 
> > > I recently came to know about FOSSASIA. It develops Open Source
> > > software and hardware solutions with a global developer community
> > > from
> > > its base in Asia and organizes Open Technology events around the
> > > year.
> > > 
> > > FOSSASIA's annual Summit in Singapore is the premier Open
> > > Technology
> > > event in Asia for developers, tech companies, and contributors.
> > > [1]
> > > 
> > > FOSSASIA Summit 2023 will be an in-person and online event,
> > > taking
> > > place from Thursday 13th April to Saturday 15th April at Lifelong
> > > Learning Institute Singapore.
> > > I believe it would be a good event to have Apache Software
> > > Foundation's presence.
> > > 
> > > I reached out to the organizers and they are happy to offer us a
> > > free
> > > booth along with three complimentary event tickets.
> > > 
> > > Is someone planning to be at the event and would like to
> > > volunteer
> > > for
> > > the booth (maybe those residing in or near Singapore)?
> > 
> > 
> > I will be speaking at the event, and can volunteer *some* time for
> > a
> > booth, but am not able to run it, manage it, or staff it full-time,
> > as
> > I have other obligations that week.
> > 
> > --Rich
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> > 
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Discussion] ASF Booth at FOSSASIA 2023

[rbowen]

On Tue, 2023-02-28 at 18:27 +0530, Priya Sharma wrote:
> Hello All,
> 
> I recently came to know about FOSSASIA. It develops Open Source
> software and hardware solutions with a global developer community
> from
> its base in Asia and organizes Open Technology events around the
> year.
> 
> FOSSASIA's annual Summit in Singapore is the premier Open Technology
> event in Asia for developers, tech companies, and contributors. [1]
> 
> FOSSASIA Summit 2023 will be an in-person and online event, taking
> place from Thursday 13th April to Saturday 15th April at Lifelong
> Learning Institute Singapore.
> I believe it would be a good event to have Apache Software
> Foundation's presence.
> 
> I reached out to the organizers and they are happy to offer us a free
> booth along with three complimentary event tickets.
> 
> Is someone planning to be at the event and would like to volunteer
> for
> the booth (maybe those residing in or near Singapore)?


I will be speaking at the event, and can volunteer *some* time for a
booth, but am not able to run it, manage it, or staff it full-time, as
I have other obligations that week.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Patch for reporter.a.o

[rbowen]

On Tue, 2023-02-14 at 14:33 -0800, Andrew Musselman wrote:
> Looks good to me. Maybe similar language on this page
> too? https://reporter.apache.org/wizard/statistics?lucene 

That page is generated by the code affected by that patch.

> 
> This ticket could be a good link to point the "Patches welcome"
> to: COMDEV-487
> 
> On Tue, Feb 14, 2023 at 1:22 PM  wrote:
> > I'd like to propose the attached patch to reporter.a.o so that
> > people
> > don't keep submitting the same mailing list stats, quarter after
> > quarter, a year after that part of the reporter is broken.
> > 
> > Thoughts?
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Apache is unable to access /tmp in any way

[rbowen]

Unfortunately, you have reached the wrong mailing list for this
question. We encourage you to email the us...@httpd.apache.org mailing
list for this question. More info is available at
https://httpd.apache.org/lists.html



On Wed, 2023-02-15 at 16:42 +0800, accelerator0099 wrote:
> This problem happened in a recent apache release before version
> 2.4.55. 
> I encountered this after a system upgrade a month ago.
> 
> 
> Apache is unable to access /tmp in any way.
> 
> 
> We may let apache host some external websites by:
> 
>  > Alias "/ext" "/path/to/external"
>  > 
>  >     Options Indexes
>  >     Require all granted
>  > 
> 
> 
> You can access that through http://yourwebsite/ext
> 
> This works most of the time. Changing "/path/to/external" to any path
> works fine including /bin, /srv, /etc ...
> 
> Except for anything under /tmp.
> 
> I always get 403 Forbidden for that.
> 
> For other directories, as long as apache has access permission on
> them, 
> I could always get their content listed.
> 
> Only for /tmp I get 403 Forbidden.
> 
> Indexing (/ext) and actual file accessing (/ext/index.html) are both 
> forbidden.
> 
> 
> Why is /tmp different from others?
> 
> Changing permission of /tmp to 755 does not work, either.
> 
> 
> Debug log here:
> 
>  > [authz_core:debug] [pid 4469:tid 140408108734144] 
> mod_authz_core.c(815): [client 127.0.0.1:37804] AH01626:
> authorization 
> result of Require all denied: denied
>  > [authz_core:debug] [pid 4469:tid 140408108734144] 
> mod_authz_core.c(815): [client 127.0.0.1:37804] AH01626:
> authorization 
> result of : denied
>  > [authz_core:error] [pid 4469:tid 140408108734144] [client 
> 127.0.0.1:37804] AH01630: client denied by server configuration:
> /tmp/http
> 
> 
> Build options:
> 
>  > ./configure --sbindir=/usr/bin \
>  > --enable-layout=Arch \
>  > --enable-mpms-shared=all \
>  > --enable-modules=all \
>  > --enable-mods-shared=all \
>  > --enable-so \
>  > --enable-suexec \
>  > --with-suexec-caller=http \
>  > --with-suexec-docroot=/srv/http \
>  > --with-suexec-logfile=/var/log/httpd/suexec.log \
>  > --with-suexec-bin=/usr/bin/suexec \
>  > --with-suexec-uidmin=99 --with-suexec-gidmin=99 \
>  > --enable-ldap --enable-authnz-ldap --enable-authnz-fcgi \
>  > --enable-cache --enable-disk-cache --enable-mem-cache 
> --enable-file-cache \
>  > --enable-ssl --with-ssl \
>  > --enable-deflate --enable-cgi --enable-cgid \
>  > --enable-proxy --enable-proxy-connect \
>  > --enable-proxy-http --enable-proxy-ftp \
>  > --enable-dbd --enable-imagemap --enable-ident --enable-cern-
> meta \
>  > --enable-lua --enable-xml2enc --enable-http2 \
>  > --enable-proxy-http2 --enable-md --enable-brotli \
>  > --with-apr=/usr/bin/apr-1-config \
>  > --with-apr-util=/usr/bin/apu-1-config \
>  > --with-pcre2
> 
> 
> Source:
> 
> https://www.apache.org/dist/httpd/httpd-2.4.55.tar.bz2
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Patch for reporter.a.o

[rbowen]

I'd like to propose the attached patch to reporter.a.o so that people
don't keep submitting the same mailing list stats, quarter after
quarter, a year after that part of the reporter is broken.

Thoughts?
Index: source/generators.js
===
--- source/generators.js(revision 1907541)
+++ source/generators.js(working copy)
@@ -455,7 +455,7 @@
 // Append header IF there is data, otherwise nah.
 if (txt.length > 0) {
   txt = "See full metrics (new tab)".format(project) + txt;
-  txt = "Potentially useful observations on community 
health:" + txt + "";
+  txt = "Please note that this part of the report is broken. Patches 
welcome:" + txt + "";
   txt += "PLEASE DON'T COPY 
THESE METRICS INTO THE REPORT ALONE!While these metrics might offer 
insights into the wellbeing of the project, what the board of directors 
 wants to see is the story behind these 
metrics.Please take some time to explain why these metrics are the way 
they are, and what this means for the project. If you are unsure how to do 
this, please take a look at some of the examples provided above  (click the 
button!).";
 }
 return txt;
Index: wizard.js
===
--- wizard.js   (revision 1907541)
+++ wizard.js   (working copy)
@@ -1669,7 +1669,7 @@
 // Append header IF there is data, otherwise nah.
 if (txt.length > 0) {
   txt = "See full metrics (new tab)".format(project) + txt;
-  txt = "Potentially useful observations on community 
health:" + txt + "";
+  txt = "Please note that this part of the report is broken. Patches 
welcome:" + txt + "";
   txt += "PLEASE DON'T COPY 
THESE METRICS INTO THE REPORT ALONE!While these metrics might offer 
insights into the wellbeing of the project, what the board of directors 
 wants to see is the story behind these 
metrics.Please take some time to explain why these metrics are the way 
they are, and what this means for the project. If you are unsure how to do 
this, please take a look at some of the examples provided above  (click the 
button!).";
 }
 return txt;

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: stats in https://reporter.apache.org seems outdated

[rbowen]

On Tue, 2023-02-07 at 10:11 -0500, rbo...@rcbowen.com wrote:
> On Mon, 2023-02-06 at 20:57 -0800, Jun Rao wrote:
> > Hi,
> > 
> > Over the last 2 quarters, I noticed that in
> > https://reporter.apache.org/wizard/statistics?kafka, the dev and
> > user
> > mail
> > stats under "Notable mailing list trends" seems outdated and
> > doesn't
> > match
> > the numbers in the graphs below. Does anyone know how to address
> > this
> > issue?
> 
> 
> Yes, this is, I believe, a known issue.

I'll also note that, as a director (others may feel differently) I
don't find that aspect of project reports even a little useful, so I
really don't care if that feature works. Tell me how your community is
doing in ways other than "dev list traffic dropped by 3%". This is
particularly the case as more and more mailing lists become inundated
by automated emails, rather than actual human communication.

> 
> The reporter tool is maintained on a volunteer basis by the ComDev
> group, and doesn't currently have a lot of activity. The code is at
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org and
> patches
> are gleefully welcomed if anyone wants to dig in and improve it.
> 
> (Sorry, yeah, I know that "patches welcome" responses are not always
> helpful, but that's where we are right now.)


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: stats in https://reporter.apache.org seems outdated

[rbowen]

On Mon, 2023-02-06 at 20:57 -0800, Jun Rao wrote:
> Hi,
> 
> Over the last 2 quarters, I noticed that in
> https://reporter.apache.org/wizard/statistics?kafka, the dev and user
> mail
> stats under "Notable mailing list trends" seems outdated and doesn't
> match
> the numbers in the graphs below. Does anyone know how to address this
> issue?


Yes, this is, I believe, a known issue.

The reporter tool is maintained on a volunteer basis by the ComDev
group, and doesn't currently have a lot of activity. The code is at
https://svn.apache.org/repos/asf/comdev/reporter.apache.org and patches
are gleefully welcomed if anyone wants to dig in and improve it.

(Sorry, yeah, I know that "patches welcome" responses are not always
helpful, but that's where we are right now.)

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Authorization required for translating “Trillions and Trillions Served”

[rbowen]

On Mon, 2022-12-19 at 11:29 +, Liu Ted wrote:
> Hi, Does anyone know what authorization is required by the ASF if one
> wanted to translate and/or use the content of this "Trillions and
> Trillions Served"?
> https://www.youtube.com/watch?v=JUt2nb0mgwg


As far as I am aware, all content posted to YouTube by The ASF is
Creative Commons Attribution. However you may wish to check with
pr...@apache.org for confirmation.

--Rich

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Starting ACEU24 preparation

[rbowen]

Taking the liberty to add planners@apachecon to this, since that's
where ApacheCon planning happens.

On Wed, 2022-12-21 at 17:45 +0100, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> With some European Apache foxes, we had a couple of meetings to
> propose a plan about ApacheCon Europe 24 (ACEU24).
> 
> We discussed the format, and we think ACEU in February 2024, in
> Brussels, the week before or after FOSDEM.
> We think it's a good option because:
> - February is pretty quiet in terms of conferences
> - Brussels is pretty easy to reach from everywhere (especially in
> Europe)
> - Brussels is not so expensive in February
> - Before or after FOSDEM will "feed" us with developers

Not a veto, but ...

Having two major events back-to-back is very challenging for most of
us. I know FOSDEM is a weekend thing, but there's so many peripheral
events that orbit FOSDEM that many of us are already on an extended
odyssey around that time.

> The format would be 2 or 3 days depending on the organization team we
> will have (to handle different tracks/talks, etc).
> 
> We now have to "recruit" a team, including a couple of relays in
> Brussels, to:
> 1. List possible venues with budget (the budget should include venue
> with exhibition space, food&drink, and eventually one offsite event
> for committers, why not beer tasting on Grand Place ;))
> 2. Find sponsors
> 3. Prepare CFP/tracks
> 
> We have #aceu24 channel on The-ASF slack and I would like to create a
> mailing list to start the concrete preparation.
> 
> If you want to help, please let us know and join the #aceu24 !

I am certainly available for whatever y'all need, but I have to admit
that having someone else at the helm makes me happy. :) 



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Release date for xalan 2.7.3 dependency

[rbowen]

On Mon, 2022-11-28 at 20:33 +0530, VenkataNagarjun Rachakuntla wrote:
> Hi apache team ,
> 
> Any release date planned for xalan java 2.7.3 dependency.
> 
> Could you please share us , we need to resolve existing vulnerability
> 
> Thanks


You need to take this question to the Xalan mailing lists:
https://lists.apache.org/list.html?xalan.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Question]About promotion ambassador

[rbowen]

On Fri, 2022-05-13 at 20:07 +0100, Geertjan Wielenga wrote:
> I’d love to know who the specific people are that I should reach out
> to per
> Apache project to discuss collaboration around events, promotions of
> our
> projects, etc.
> 
> If the answer to the above is “write to their mailing list” or
> “everyone”,
> etc, then no that’s not what I mean.

I tend to think that the answer *should* be write to the mailing list,
but that *also* there should be people who consider it their role to
step up and answer those questions.

Why both? Because we do things in the view of the entire community, so
that 1) people can see answers to questions that they may have, but
haven't asked yet and 2) people see the conversation and think "I could
do that too" and then step in the next time.

When the answer is "Email Larry", then 1) only Larry sees the questions
and they don't benefit anybody else and 2) the rest of the community is
told, implicitly, back off, that's not your cookie.



-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Question]About promotion ambassador

[rbowen]

On Fri, 2022-05-13 at 16:43 +0100, Geertjan Wielenga wrote:
> Yes, this is well established and is not at all under scrutiny at
> all.
> 
> What I’m suggesting is that the denotation of “advocate” (on top of
> or
> separate from alternative denotations) and a list of those friendly
> people
> who might want to collaborate in the outside non-code world might be
> nice.
> 
> Yes, we can go to the well established responses to this or… just for
> this
> time… maybe not?


Well, like I said, there are projects that do designate such a role.
Josh, for example, plays that role for Heron, and Jarek does for
Airflow.

I, for one, encourage projects to designate a community manager, an
events coordinator, a publicist - as long as it's clear that they're
not the only person allowed to do those activities.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [Question]About promotion ambassador

[rbowen]

On Fri, 2022-05-13 at 22:57 +0800, Evil Cat wrote:
> Hi guys,
> 
> 
>     I know that Apache TLP currently has two roles of Committer and
> PMC, 
> but I would like to ask if there is a role of promotion ambassador
> (event planning, community evangelism), 
> although I know that Committer and PMC also have such accusations,
> there seems to be a clearer role like Promoter Ambassador,
>  so I wanted to ask if we have an official role like Promoter
> Ambassador.

Some projects have someone designated in a role like that.

However, do note that "committer" does not necessarily imply committing
code, but, rather, one who is committed to the project. It covers all
involvement in projects including code, docs, design, events,
promotion, and so on. As such, a project SHOULD make someone a
committer for none-code contributions.


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: A way to keep the name

[rbowen]

On Wed, 2022-05-11 at 14:56 -0400, me wrote:
> This is more or less in line with what I think we’ve anticipated. I
> really appreciate you providing the info. 
> 
> That said… to outreach or not to outreach… that is the question. 

So ... I have been staying out of this conversation rather
intentionally for a number of reasons, but I feel I must speak up here.

YOU MUST NOT reach out to ANYONE on behalf of the Apache Software
Foundation without coordinating with M&P. Without their approval, you
are NOT authorized to speak on behalf of the ASF, or put yourself in a
position where it appears that you are doing so.


Please forgive if I am coming across stronger than warranted here, but
this is a line that you MUST NOT cross without the approval of M&P.

Thanks.

--Rich, with Board of Directors hat on.




> I’m going to try to remain impartial in order to facilitate. (i.e.
> this isn’t my opinion, I’m just trying to help move things forward).
> 
> The scenario w/ Jeep is the most synonymous to Apache. (We are named
> for a tribe, rather than a synonymous term or epithet). I’m side
> stepping the logo for the moment. 
> 
> The last words I could find on the subject (w/ a brief scan) were
> March of 2021
> 
> - Chief Hoskins of the Cherokee Nation did request a name change from
> Jeep. 
> - Jeep opened up talks, but they didn’t comply.
> 
> 
> 
> 
> From: Roman Shaposhnik 
> Reply: Roman Shaposhnik 
> Date: May 9, 2022 at 09:52:47
> To: me 
> Cc: ComDev 
> Subject:  Re: A way to keep the name  
> 
> On Mon, May 9, 2022 at 4:35 PM me  wrote:  
> >  
> > Roman, welcome to the party!  
> 
> LOL! Thanks ;-)  
> 
> > I think the scope of the risk (in terms of “what”) is fairly well
> > understood. Did you also estimate the probability of the risks?
> > (i.e. likelihood?)  
> 
> IIRC mostly the likelihood.  
> 
> > Do you mind sharing what the results were of the previous
> > assessment?  
> 
> It was deemed to be low: primarily based on our historic use of the  
> name (we have been pretty respectful with it) and the fact that  
> whoever brings the lawsuit will have to have a standing.  
> 
> Thanks,  
> Roman.  


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org