[DISCUSS] OSS-bot project sponsored by comdev

[Craig Russell]

Hi,

tldr; I'd like to discuss whether comdev is interested in sponsoring a robot 
project to help communications in the Chinese Apache community.

At ApacheCon 2019 in Las Vegas, several people from the Chinese Apache 
community and members of comdev met to discuss how to improve communications. 
Several issues were raised, including the widespread use of chat-like social 
media for communications instead of mail lists.

I subsequently met with several people in Beijing while attending the Tencent 
Techo conference. We discussed technical approaches to helping with 
communications, and started to focus on a robot to help manage social media 
with the goal of meeting Apache requirements for "important" project 
communications:
- archived message storage
- English language 
- permanent message storage
- searchable message storage

I proposed starting an incubator podling to help guide them in the Apache Way
https://cwiki.apache.org/confluence/display/INCUBATOR/OSSBotProposal
Several people have already volunteered to help mentor the project, including 
Ted Liu, Liang Zhang, Willem Jiang, Junping Du and Craig Russell.

But there are a few reasons that incubating now might not be the right path:
- many of the tools are open source with their own communities
- it is not clear what the code deliverable would be from the podling

There are now several people involved in the project, and they have started 
having regular meetings. 
https://docs.google.com/document/d/1K3-rbiIUDSJoGyH0g4zEvhYZL2T6HsKgfsiI0xCCCa0/comment

There are several Apache podlings with an interest in this project, including 
DolphinScheduler, Doris, IoTDB, ShardingSphere and Weex. 

The question I'd like to raise here is whether comdev is interested in 
sponsoring this project, which would involve creating a mail list for the 
project and some amount of infrastructure to run the proof of concept/pilot 
robot.

Craig L Russell
c...@apache.org


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

Re: [DISCUSS] OSS-bot project sponsored by comdev

[Craig Russell]

Hi Ray,

> On Nov 29, 2019, at 6:52 PM, Ray Ma  wrote:
> 
> Hi Craig,
> 
> If the Incubator was to accept this project for incubation, what does that
> mean for the current policy on acceptable communication channels? Would
> methods other than apache lists be acceptable as "official", as long as
> they use this project?

This is a proof of concept and it's premature to discuss changing policy.

Regards,
Craig
> 
> Thanks,
> Ray
> 
> On Sat, Nov 30, 2019 at 11:02 AM Craig Russell  wrote:
> 
>> Hi,
>> 
>> tldr; I'd like to discuss whether comdev is interested in sponsoring a
>> robot project to help communications in the Chinese Apache community.
>> 
>> At ApacheCon 2019 in Las Vegas, several people from the Chinese Apache
>> community and members of comdev met to discuss how to improve
>> communications. Several issues were raised, including the widespread use of
>> chat-like social media for communications instead of mail lists.
>> 
>> I subsequently met with several people in Beijing while attending the
>> Tencent Techo conference. We discussed technical approaches to helping with
>> communications, and started to focus on a robot to help manage social media
>> with the goal of meeting Apache requirements for "important" project
>> communications:
>> - archived message storage
>> - English language
>> - permanent message storage
>> - searchable message storage
>> 
>> I proposed starting an incubator podling to help guide them in the Apache
>> Way
>> https://cwiki.apache.org/confluence/display/INCUBATOR/OSSBotProposal
>> Several people have already volunteered to help mentor the project,
>> including Ted Liu, Liang Zhang, Willem Jiang, Junping Du and Craig Russell.
>> 
>> But there are a few reasons that incubating now might not be the right
>> path:
>> - many of the tools are open source with their own communities
>> - it is not clear what the code deliverable would be from the podling
>> 
>> There are now several people involved in the project, and they have
>> started having regular meetings.
>> 
>> https://docs.google.com/document/d/1K3-rbiIUDSJoGyH0g4zEvhYZL2T6HsKgfsiI0xCCCa0/comment
>> 
>> There are several Apache podlings with an interest in this project,
>> including DolphinScheduler, Doris, IoTDB, ShardingSphere and Weex.
>> 
>> The question I'd like to raise here is whether comdev is interested in
>> sponsoring this project, which would involve creating a mail list for the
>> project and some amount of infrastructure to run the proof of concept/pilot
>> robot.
>> 
>> Craig L Russell
>> c...@apache.org
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 

Craig L Russell
c...@apache.org


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

Re: ALC, and who can speak on behalf of Apache

[Craig Russell]

Hi Swapnil,

I realize I'm coming late to this discussion but would like to offer a small 
bit of feedback.

Like others, I think we need to try to get qualified people running local 
groups. One Member plus two PMC members gives us three, which is a magic number 
for decision-making here. Even if they don't attend all meetings, it's at least 
some oversight from folks who have earned merit.

Random talks that present how we do things here, by people we don't know, makes 
me nervous. We might consider requiring presentations to be posted publicly 
some time (one week?) before the meeting which would allow for at least some 
oversight. 

And there are plenty of such presentations publicly available and some can be 
edited to suit (e.g. see the Training podling for examples of presentations on 
The Apache Way).

I endorse the concept and look forward to a proposal.

Craig

> On Dec 11, 2019, at 11:59 AM, Swapnil M Mane  wrote:
> 
> Thank you so much, everyone, for your kind and valuable inputs.
> As a next step, we will work on drafting the ALC proposal to the board.
> 
> 
> - Best regards,
> Swapnil M Mane,
> www.apache.org
> 
> On Thu, Dec 12, 2019 at 12:20 AM Rich Bowen  wrote:
>> 
>> 
>> 
>> On 12/6/19 4:42 PM, Roman Shaposhnik wrote:
>>> One potential (if not solution -- but at least a line of thought) could be
>>> to bring these efforts into the fold officially by requiring them to be
>>> official sub-projects of ComDev PMC. Then we can have a policy requiring
>>> a certain governance oversight over those sub-projects (like requiring
>>> a certain # of PMC/members, etc.).
>> 
>> This just feels like too much structure/bureaucracy to me. We want just
>> enough oversight, but we don't want to kill it with too much, either.
>> 
>> If, at some later date, this grows to the point where it seems to *need*
>> this much oversight, then, great, we take that step then.
>> 
>> Small, reversible steps.
>> 
>> --
>> Rich Bowen - rbo...@rcbowen.com
>> http://rcbowen.com/
>> @rbowen
>> 
>> -
>> 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
> 

Craig L Russell
c...@apache.org


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

Looking for community development stories

[Craig Russell]

Hi,

I'm working on a presentation to the Huawei Developer Conference in Shenzhen 
February 11 on the subject of "Growing Communities The Apache Way".

I'd like to share with the audience some stories of Apache Projects that have 
grown their communities, either in the incubator or after becoming a top level 
project.

What I'd like is some facts to discuss, e.g. community makeup before entering 
incubator, community exiting incubator, any special actions done by the 
community to encourage growth, etc. With some details, I can share the 
projects' successes with the developers at the conference.

Any help is very appreciated. I'll need any input by Friday January 31 (10 days 
from now; a day before FOSDEM).

Thanks,

Craig

Craig L Russell
c...@apache.org


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

Re: [Announcement] - Establishing ALC Beijing Chapter

[Craig Russell]

Congratulations to everyone involved in the new ALC in Beijing.

I can only imagine how hard it is for you during the coronavirus situation and 
wish you a speedy resolution to the crisis.

Best regards,
Craig

> On Feb 18, 2020, at 3:02 AM, Swapnil M Mane  wrote:
> 
> Hello all,
> 
> ComDev PMC is pleased to announce our next ALC Chapter, ALC Beijing
> [1] and Willem Jiang as ALC Beijing Chapter lead.
> We have the following members in ALC Beijing:
> 
> 1. Willem Jiang
> -- ASF Member
> -- Chair, Servicecomb
> -- PMC (Camel, CXF, Incubator, RocketMQ, ServiceMix, SkyWalking)
> 
> 2. Jeff Zhang
> -- ASF Member
> -- PMC (Tez, Zeppelin)
> -- Committer (Incubator, Pig, Submarine, Livy)
> 
> 3. Hadrian Zbarcea
> -- ASF Member
> -- PMC (Brooklyn, Camel, Incubator, TinkerPop)
> -- Non-PMC (Fundraising)
> -- Committer (ActiveMQ, Labs)
> 
> 4. Liu Ted
> -- ASF Member
> -- PMC (Incubator)
> -- Non-PMC (Fundraising)
> 
> 5. Sheng Wu
> -- Chair, SkyWalking
> -- PMC (Incubator)
> -- Committer (DolphinScheduler, ECharts, and ShardingSphere)
> 
> 6. Liang Zhang
> -- PMC (Dubbo)
> -- Committer (Incubator, ShardingSphere)
> 
> 7. Jincheng Sun
> -- PMC (Flink)
> -- Committer (Incubator, IoTDB)
> 
> 8. Xiangdong Huang
> -- Committer (Incubator, IoTDB)
> 
> 9. Juan Pan
> -- Committer (ShardingSphere, Incubator)
> 
> 10. Skylar Deranick
> 
> Please join me in congratulating the ALC Beijing Chapter and wishing
> them the best luck for their future events.
> 
> [1] https://s.apache.org/alc-beijing
> 
> 
> Best regards,
> Swapnil M Mane,
> www.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: [ALC] ALC Warsaw Event

[Craig Russell]

+1
LGTM

Craig

> On Mar 31, 2020, at 10:30 AM, Tomasz Urbaszek  wrote:
> 
> Hello,
> 
> As per ALC Event guidelines [1], we would like to ask for PMC approval
> for the upcoming ALC Warsaw Event. The detailed agenda and speakers
> can be found on the confluence page dedicated to this event:
> https://cwiki.apache.org/confluence/display/COMDEV/ALC+Warsaw+Meetup+%231
> 
> The event will be an online meetup due to the current situation and
> will be held on 7th of April.
> 
> [1] https://s.apache.org/alc-guidelines
> 
> Tomek Urbaszek,
> Chapter Lead, ALC Warsaw
> https://s.apache.org/alc-warsaw
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: [VOTE] ALC Website with Git/Hugo framework

[Craig Russell]

+1 (non-binding)

Craig

> On Mar 31, 2020, at 10:30 PM, Swapnil M Mane  wrote:
> 
> Hello team,
> 
> We had a discussion on setting up the Apache Local Community (ALC) [1]
> initiative website at
> https://s.apache.org/4ge6w
> 
> Here is the summary for the discussion,
> 
> 1. ALC website will be hosted at alc.apache.org
> 2. Each chapter will have subpage like alc.apache.org/beijing
> And a new post can be contributed by ALC Chapter to their spaces.
> 3. The Hugo framework will be used for building the website.
> 
> Looking at the thread seems a majority of people are in agreement with
> setting up the site.
> I would like to initiate a formal vote for establishing the ALC
> Website with Git/Hugo.
> 
> Please vote:
> [ ] +1 to setup ALC Website with Git/Hugo
> [ ] -1 for not having ALC Website
> 
> 
> [1] https://s.apache.org/alc
> 
> Best regards,
> Swapnil M Mane,
> www.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Question for can not access reporter.apache.org

[Craig Russell]

I think it takes a while for these tools to catch up with reality.

I can see ShardingSphere in the All Projects section of the tool.

Is it ok now for you?

Craig

> On Apr 22, 2020, at 1:03 AM, zhangli...@apache.org wrote:
> 
> Hi,
> 
> I cannot access project shardingsphere in https://reporter.apache.org/, but
> I can see dubbo.
> Maybe something wrong with the configuration
> 
> The details is in JIRA ticket:
> https://issues.apache.org/jira/browse/INFRA-20135
> 
> Please advice me. Thank you very much.
> 
> --
> 
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo

Craig L Russell
c...@apache.org


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

Fwd: Multilingual Content (forwarded from apachecon planners discussion)

[Craig Russell]

I think this may be worth a discussion here. I am totally in favor of being 
more inclusive by having presentations about Apache in multiple languages.

There have been many presentations to non-English-native-listeners about Apache 
topics.

I am a small bit concerned that translations of presentations might not fully 
capture the content of the original. Seeing a presentation in English by an 
English speaker and seeing the translated presentation in e.g. Chinese by a 
Chinese speaker is possibly not a good way to verify that the message was 
completely translated.

Would it be too much to ask for such presentations to include on each slide 
both the English and Chinese? I understand that there are challenges with this 
approach but it would perhaps make it easier to verify that the translation is 
topic-by-topic. It might also make "the same talk in two recordings" easier to 
implement.

Regards,
Craig

> Begin forwarded message:
> 
> From: Julian Feinauer 
> Subject: Multilangual Content
> Date: May 29, 2020 at 4:10:04 AM PDT
> To: "plann...@apachecon.com" 
> Reply-To: plann...@apachecon.com
> 
> Hi all,
>  
> I considered organizing a Track for the IoTDB project. This project is (like 
> others also) with strong community in China. And we are „bilateral“ in the 
> project as we try to provide enough information in both languages that also 
> the not-so-fluent english speaking Chinese Community can follow.
>  
> Would it be possible to have presentations / videos in other Languages? Or 
> probably the same talk in two recordings?
> Are there general objections with the idea? I think this could be really cool 
> for projects like IoTDB to reach the Chinese Community.
>  
> Julian

Craig L Russell
c...@apache.org

Re: [ALC]ALC Beijing Meetup August 16

[Craig Russell]

Hi,

Just for my understanding: 

is the event 14:00 ~ 17:30 in Beijing time? 
is the event in Chinese?

Thanks,
Craig

> On Aug 10, 2020, at 8:53 PM, 适兕  wrote:
> 
> Hello everyone,
> 
> The ALC [1] Beijing Chapter [2] will host a meetup (support online
> participation)  this weekend.
> 
> This time we choose the topic : “How to remove the roadblocks on the open
> source journey”
> 
> We invited Apache Flink and Apache DolphinScheduler(Incubating) PPMC to
> share their stories. and invited 5 guests to discuss this topic ,They are
> all very experienced in open source.
> 
> more information ( time,location and online url etc.) please go to [3], or
> reply to this email.
> 
> Welcome to join us !
> 
> [1] https://s.apache.org/alc
> [2] https://s.apache.org/alc-beijing
> [3]
> https://cwiki.apache.org/confluence/pages/editpage.action?pageId=158868125
> -- 
> Welcome to http://opensourceway.community! The open source way:  Dedicated
> to the exploration of ideas, knowledge and values related to open source.

Craig L Russell
c...@apache.org


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

Re: Audit of sub-processors 2020

[Craig Russell]

There is no need for the project or Apache to do anything with this request.

If you want to be polite, I'd say it's ok to respond and let them know that 
we're not going to take any action whatsoever. Just to avoid them "reminding" 
us...

Craig

> On Nov 17, 2020, at 6:08 AM, David Smiley  wrote:
> 
> I'm not sure what to make of this document.  On occasion, organizations doing 
> some sort of audit of their software sometimes send forms to open-source 
> projects, expecting the maintainers of the project to fill it out.  It's rare 
> for such forms to be filled out; I think it's up to your organization to try 
> and discover what you need to know.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, Nov 17, 2020 at 3:10 AM Elisabeth Overlund Andersen  > wrote:
> Hi there,
> 
>  
> 
> We are currently conducting our yearly audit of sub-processors, and we 
> continuously use SOLR Apache in our software developing department.
> 
>  
> 
> Therefore we would like you to answer the attached document before 24th of 
> November 2020.
> 
>  
> 
> If you have other relevant documentation or a SOC report you can send me this 
> instead.
> 
>  
> 
> I look forward to hearing from you.
> 
>  
> 
>  
> 
> Med venlig hilsen / Best Regards
> 
> ELISABETH OVERLUND ANDERSEN
> 
> HR Legal Consultant
> 
> e...@impact.dk
>  
> M
> T
> 
> +45 6039 4919
> +45 7020 1619
> 
>  
> DIGITAL COMMERCE / PEOPLE / RESULTS
> AARHUS: Søren Frichs Vej 44D - DK-8230 Åbyhøj
> KBH: Laplandsgade 4A, 2. sal - DK-2300 København S
> 
>  
> 

Craig L Russell
c...@apache.org

Re: Apache Roadshow - China recap

[Craig Russell]

Hi Ted,

Thanks for sharing this. Great work and great response from the audience!

Best regards,
Craig

> On Dec 14, 2020, at 9:33 PM, Liu Ted  wrote:
> 
> Dear Rich, Sally and Craig,
> 
> Thank you for your support the Apache Roadshow - China (co-located with 
> COSCon'20). Here comes the event summary. 
> 
> There were one million+ online viewers and hundreds of offline audiences 
> across 5 cities in China. 
> 
> 
> 
> 
> 
> Dear Craig, Thank you for your sharing which has inspired millions. 
> 
> 
> Special thanks to ALC Beijing members, Willem Jiang, Sheng Wu, Lidong Dai, 
> Juan Pan, Jiansheng Li, Liang Zhang, Xiangdong Huang, and many more 
> volunteers and Aapche fans organized by ALC Beijing.
> 
> 
> https://mp.weixin.qq.com/s?__biz=MzA5MTA2NDA5MQ==&mid=2655320841&idx=2&sn=55b2433ef9fa467485b27349820ea110&chksm=8bb2497dbcc5c06bbca2659c32e919757a417a210e090ad413562dcb5fee6fc89681f0e46aab&mpshare=1&scene=1&srcid=1214rQ6p3okxEjnikwYG2XPC&sharer_sharetime=1607996825876&sharer_shareid=24f6d3ce094d2205129bd421cf0dbe7f&exportkey=Aa66Gp47XiDYP6CQeR7Gl6E%3D&pass_ticket=Y3hi6mVayMhZU%2BaUm0iflQ3Ye8udlccmL6tmb9dtzech87d%2BSqEQOGA9tAqbC%2BFS&wx_header=0#rd
>  
> 
> 
> 
> Hi Sally, It'd be great if this could be shared on ASF media channels.
> 
> 
> Hi Rich, We, at ALC Beijing, are thinking of conducting the ApacheCon Asia 
> next year in China with multiple locations as we did in 5 cities in China 
> this year. 
> 
> 
> Best regards,
> 
> Ted Liu
> On behalf of the 2020 Apache Roadshow - China & COSCon'20 Steering Committee
> 

Craig L Russell
c...@apache.org

Moderators needed for community.apache.org lists

[Craig Russell]

It appears that there are not enough moderators for the mentors@ list. 

If you can volunteer to moderate this list (and the students@ list seems to 
have the same moderators) please speak up on this list.

I'll volunteer to moderate both lists at this time.

Regards,
Craig

Craig L Russell
c...@apache.org


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

Re: Moderators needed for community.apache.org lists

[Craig Russell]

If anyone has had trouble subscribing to the mentors@ or students@ lists please 
try again.

Thanks,
Craig

> On Feb 22, 2021, at 10:46 AM, Sharan Foga  wrote:
> 
> Hi Craig
> 
> Thanks for this.
> 
> Maxim has asked to be added as a moderator  https://s.apache.org/r52o8 and 
> has a Jira open with Infra.
> 
> I'm happy to be added as a moderator too.
> 
> Thanks
> Sharan
> 
> On 2021/02/22 16:22:46, Craig Russell  wrote: 
>> It appears that there are not enough moderators for the mentors@ list. 
>> 
>> If you can volunteer to moderate this list (and the students@ list seems to 
>> have the same moderators) please speak up on this list.
>> 
>> I'll volunteer to moderate both lists at this time.
>> 
>> Regards,
>> Craig
>> 
>> Craig L Russell
>> c...@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
> 

Craig L Russell
c...@apache.org


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

Re: One year anniversary of ALC Beijing

[Craig Russell]

Congratulations to everyone involved in the Beijing ALC on this anniversary.

I'm looking forward to meeting you all once the global disaster is under 
control.

Best,
Craig

> On Feb 26, 2021, at 4:09 PM, Willem Jiang  wrote:
> 
> Hi
> 
> 
> This is Willem Jiang, the chapter leader of Apache Local Community
> Beijing[1], and I am beyond thrilled to share with you the joy and
> excitement of ALC Beijing’s one year anniversary.
> 
> 
> ALC Beijing was officially founded on February 27th, 2020, with a
> mission of promoting Apache way and Open Source culture in China. ALC
> Beijing is committed to bringing local open source enthusiasts
> together by hosting events and publishing articles . By sharing open
> source development experience, ALC Beijing encourages more people
> (especially the university students) to participate in ASF projects.
> ALC Beijing also plays a role of facilitating the mutual cooperations
> of ASF projects. ALC Beijing aims to advocate ASF projects by working
> closely with the local developer teams to host meetups, and sharing
> the Open Source governance experience of ASF by translating the policy
> documentations.
> 
> 
> Over a year, ALC Beijing has reached a milestone in community culture
> building. Despite the fact that due to the pandemic we were not able
> to host the events in half of last year, we still managed to host 2
> ALC meetups and participated in 2 co-events[2]. We have met hundreds
> of Open Source enthusiasts in Beijing through these events. We also
> started a local social media public account (ALC Beijing official
> WeChat public account) to publish 60 articles which focus on the
> interpretation of Apache Way, the latest updates of ASF projects, and
> other related information about local projects. Now The account has
> achieved 1,600 subscribers.
> 
> 
> ALC Beijing also has published 9 original podcast episodes[3][4] on
> its own channel, and has achieved over 4,600 plays. The podcast
> included the sharing of experience from those who just graduated from
> Apache Incubator, and the success stories which could encourage more
> university students to participate in open source projects.
> 
> 
> ALC Beijing further accelerated the progress of culture-building by
> translating Apache 20 Anniversary documentary subtitles, Apache
> Incubator Cookbook and Apache License[5] so that the enthusiasts in
> China could enjoy the work with fewer language barriers.
> 
> 
> With all the help from Apache and members, ALC Beijing is determined
> to serve everyone who is interested in open source. We look forward to
> sharing with you about more accomplishments of ALC Beijing in the near
> future.
> 
> [1]https://cwiki.apache.org/confluence/display/COMDEV/ALC+Beijing
> [2]https://cwiki.apache.org/confluence/display/COMDEV/ALC+Beijing+Events
> [3]]https://podcasts.apple.com/us/podcast/alc-beijing-podcast/id1523278501?uo=4&at=1001lsYj
> [4]https://www.ximalaya.com/keji/37853515/
> [5]https://github.com/alc-beijing/translation
> 
> 
> Best regards,
> 
> Willem
> 
> 
> Twitter: willemjiang
> Weibo: 姜宁willem

Craig L Russell
c...@apache.org


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

Re: Unclear/ambiguous statement in Maturity Model - RE30

[Craig Russell]

Hi Sebb,

https://community.apache.org/apache-way/apache-project-maturity-model.html


> On Mar 8, 2021, at 3:41 AM, sebb  wrote:
> 
> What does "and/or" in RE30 really mean?
> Is it intentional?
> 
> -
> RE30
> Releases are signed and/or distributed along with digests that can be
> reliably used to validate the downloaded archives.
> -
> 
> Expanding the and/or, I read this two ways:
> 
> 1) Releases are signed and distributed along with digests that can be
> reliably used to validate the downloaded archives.
> 
> 2) Releases are signed or distributed along with digests that can be
> reliably used to validate the downloaded archives.
> 
> Statement 1 seems clear to me.

I agree. It could even be clearer that signatures and digests (SHA256 and/or 
SHA512) are both required. Maybe the type of digest was the origin of the 
and/or...
> 
> Statement 2 appears to imply that releases don't have to be signed --
> if it means anything.

I cannot parse this one either.

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

Craig L Russell
c...@apache.org


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

Re: Board reporting project stats feature broken - Email stats seem to have zero weeks

[Craig Russell]

Hi Mike,

Take this for what it's worth...

> On Mar 8, 2021, at 6:41 AM, Beckerle, Mike  
> wrote:
> 
> It appears you are correct. There is tons of activity in our commits mailing 
> list, and our private list was also busy at that time, but dev was actually 
> quiet during the period both from the mail archives and checking my own 
> deleted emails. Much discussion in our team doesn't happen on dev, but in the 
> back-and-forth on pull requests,

Some projects configure GitHub PRs so a subset of the dialog is sent to the 
dev@ list. For example, when a PR is opened, when a PR has a review, when a PR 
is merged might be good events to publish on dev.

Warm regards,
Craig

> and most discussion was on our private list related to the graduation process.
> 
> Thank you for checking.
> 
> I see that plc4x graphs look better today, so the overall issue with 2021 
> appears to be resolved as well.
> 
> Thank you
> 
> Mike Beckerle
> Apache Daffodil PMC Chair
> 
> 
> From: sharanf mailto:sha...@apache.org>>
> Sent: Sunday, March 7, 2021 10:05 AM
> To: dev@community.apache.org  
> mailto:dev@community.apache.org>>; Beckerle, Mike 
> mailto:mbecke...@owlcyberdefense.com>>
> Cc: Christofer Dutz  >
> Subject: Re: Board reporting project stats feature broken - Email stats seem 
> to have zero weeks
> 
> Hi Mike
> 
> Thanks for the bug report - we will investigate.
> 
> I took a quick look at Daffodil's dev mailing list for week 5 (8th - 14th 
> February) and I see emails for 2nd, 3rd and 4th of February and then no other 
> emails sent until 16th February. This is probably why there is nothing in the 
> email stats for week 5.  If you can find an email that was sent during week 5 
> on the list that I've missed then please send a link so that we can dig into 
> the issue some more.
> 
> I will also follow up on the others issues that you have mentioned.
> 
> Thanks
> Sharan
> 
> On 2021-03-05 15:54, Beckerle, Mike wrote:
> INFRA (D. Gruno) told me to get support for this from dev @ community.
> 
> JIRA is down right now (can't create a ticket) so I'm sending this in email.
> 
> Board reports are due shortly. The email stats are very broken.
> 
> My project
> 
> https://reporter.apache.org/wizard/statistics?daffodil
> 
> shows 1 dead week (week 5),
> 
> [cid:702ec329-1851-4e2f-bac4-c2338007ad04 
> ]
> 
> when I'm quite sure there was traffic from looking at the mail archives at
> 
> https://lists.apache.org/list.html?d...@daffodil.apache.org 
> 
> 
> This is actually improved. Yesterday there were zeros for all weeks of 2021. 
> This screenshot is from yesterday:
> [cid:3947574e-fa2b-46b3-b45a-6ba67c76aec9 
> ]
> 
> We're not the only project having this problem.
> 
> https://reporter.apache.org/wizard/statistics?plc4x 
> 
> 
> which as of this writing has same issue:
> [cid:915b4de1-20e9-4688-8fed-2c77d4567366 
> ]
> 
> Mike Beckerle | Principal Engineer
> 
> [cid:24eb95a2-7bad-4913-a38b-218d848e24cf 
> ]
> 
> mbecke...@owlcyberdefense.com 
>  >
> 
> P +1-781-330-0412
> 
> Connect with us!
> 
> [cid:d9106eb7-9508-484a-bedb-46cca6c7de97 
> ]  
> >[cid:0a4b8d2b-e338-4c2c-ae52-7beabc7153d8
>  
> ]  >
> 
> [cid:e237fe61-d373-4b2a-ae9e-cc427a8eb4a9 
> ]  >
> 
> 
> 
> The information contained in this transmission is for the personal and 
> confidential use of the individual or entity to which it is addressed. If the 
> reader is not the intended recipient, you are hereby notified that any 
> review, dissemination, or copying of this communication is strictly 
> prohibited. If you have received this transmission in error, please notify 
> the sender immediately

Craig L Russell
c...@apache.org

Re: ASF wide policy on github's squash and merge?

[Craig Russell]

Hi Antonio,

> On Apr 5, 2021, at 1:01 PM, antonio  wrote:
> 
> Hi all,
> 
> First of all, apologies if this is not the proper list to ask these sort of 
> questions. If this is the case I'd appreciate some guidance on who to ask 
> these questions.

IMHO this is a fine place to discuss this topic.

> It seems github automatically changes author [1] and contributor [2] details 
> when one presses the "Squash and Merge" button, replacing these with the 
> author name and email (if present) of the Github account (and with "GitHub 
> nore...@github.com" otherwise).
> 
> We discussed this in our mailing list a while back ([4], [5]) with no clear 
> consensus.
> 
> The questions are:
> 
> 1. Is there an ASF-wide policy (or consensus) on how to handle this "Squash & 
> Merge" feature in github? Or is this a project-specific decision?

I believe this is a project-specific decision to make. Some projects (Netbeans) 
are discussing disabling the feature in order to preserve contributors for 
patches.

But other projects (JDO) discussed this and agreed that the default should be 
squash and merge because if a patch has many iterations, the commit history 
gets very messy and it's hard to trace the progress of the patch as it wanders 
through several stages.
> 
> 2. Does the ASF want to keep track of contributor names/emails when PRs are 
> received+squashed+merged via github or is this Github behaviour ok?

I would just caution projects to carefully consider the possibility of losing 
provenance if using squash-merge protocols, especially if contributions are 
being merged from non-committers.

Regards,
Craig
> 
> Thanks for any guidance,
> Antonio
> 
> 
> [1]
> Pull request "Squash and merge" button changes author details #1368
> https://github.com/isaacs/github/issues/1368
> 
> [2]
> Contributors of squashed commits don't get any love #1303
> https://github.com/isaacs/github/issues/1303
> 
> [3]
> Merging on github (aka Squash and Merge is broken)
> http://mail-archives.apache.org/mod_mbox/netbeans-dev/201912.mbox/%3C6157b71ba7974359a3d1b9ae83bbb4a0ea2c9b2d.camel%40doppel-helix.eu%3E
> 
> [4]
> [DISCUSS] github: Disable squash-and-merge button
> http://mail-archives.apache.org/mod_mbox/netbeans-dev/202005.mbox/%3C76c36442eb90d3b4c6bfe76c51127549d05bc34e.camel%40doppel-helix.eu%3E
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: New Apache.org product concept: Digital Merit Badges

[Craig Russell]

Hi Matthew,

Your message makes me think you did not get past Daniel's first eight words.

If you read the message, he gives a few reasons to dislike badges.

Your snarky response is not a good example of healthy community discussion.

Craig

> On Apr 5, 2021, at 4:14 PM, Matthew Sacks  wrote:
> 
> Thanks for your input.
> 
> “I don’t like it” is your only reason?
> 
> Perhaps we should get rid of the corporate thank you page?
> 
> 
> 
> On Mon, Apr 5, 2021 at 1:47 PM Daniel Ferradal  wrote:
> 
>> Hello,
>> 
>> In my humble opinion, I don't like labels, medals, awards, bands,
>> distinctions, badges, ribbons, stars, trophies or anything similar
>> that distinguish anyone from any other. As I see it, it's a form of
>> manipulation to persuade people to achieve more than they might want
>> and may probably lead to people feeling better than others or just the
>> opposite, which is worse.
>> 
>> ASF being what it is, all volunteers doing whatever they can or want,
>> time, life, family or will permits,  but a necessary few that work
>> professionally to maintain operation, I don't like the idea of using
>> this kind of "corporate encouragement".
>> 
>> I understand the idea behind this is probably well meant, but that
>> does not make me like it anyway.
>> 
>> Cheers.
>> 
>> El lun, 5 abr 2021 a las 18:06, Matthew Sacks
>> () escribió:
>>> 
>>> If I can get a vm as you suggested I’m happy to start a PoC.
>>> 
>>> 
>>> On Mon, Apr 5, 2021 at 8:52 AM Rich Bowen  wrote:
>>> 
 
 
 On 4/5/21 10:46 AM, Matthew Sacks wrote:
> So far response has been more yay than nay.
> 
> Next steps to turn this into a teak initiative?
> 
> Vote?
> 
> Podling setup or is this going to be an Infra service?
 
 There are, I believe, two possible ways forward here:
 
 1) We request a VM from infra, and someone volunteers to stand this up
 and maintain it.
 
 2) We persuade Infra that this is a necessary service that they should
 host for the Foundation.
 
 My recommendation would be to go route 1 to start, and then judge,
>> based
 on adoption, whether 2 is justified. The problem with 1, of course, is
 that it requires a volunteer who is willing to move forward with it and
 keep it alive.
 
> 
> The https://www.badgr.org looks like a good way to implement, maybe.
> 
> 
> On Mon, Apr 5, 2021 at 7:25 AM Matt Sicker  wrote:
> 
>> This sounds cool!
>> 
>> On Mon, 5 Apr 2021 at 08:20, lidong dai 
>> wrote:
>>> 
>>> wow, I like this idea very much!
>>> 
>>> 
>>> 
>>> Best Regards
>>> ---
>>> DolphinScheduler PMC chair
>>> Lidong Dai
>>> dailidon...@gmail.com
>>> ---
>>> 
>>> 
>>> On Mon, Apr 5, 2021 at 9:16 PM Matthew Sacks <
>> matt...@matthewsacks.com
> 
>>> wrote:
>>> 
 Note text: “something like”. I didn’t advocate using NFT’s
>> themselves.
 
 
 On Mon, Apr 5, 2021 at 5:43 AM Jarek Potiuk 
>> wrote:
 
> AaaaH .. No NFT please :).
> 
> J.
> 
> 
> On Mon, Apr 5, 2021 at 2:30 PM Matthew Sacks <
>> matt...@matthewsacks.com>
> wrote:
> 
>> Does Badgr have some kind of certification method to validate
>> the
>> badge
>> authenticity?
>> 
>> I was thinking something like NFT’s for the badge graphic.
>> 
>> 
>> On Mon, Apr 5, 2021 at 5:26 AM Rich Bowen 
>> wrote:
>> 
>>> 
>>> 
>>> On 4/5/21 8:19 AM, Daniel Gruno wrote:
 I had a similar idea some years back, but with a slightly more
 tongue-in-cheek approach.
 
 Some sample "merits" I had in mind then:
 
 - 1,000 commits within a year
 - 5,000 commits in total
 - 1,000 emails to our lists
 - Annoyed Sally more than 5 times
 - Caused at least one CVE
 - *Fixed* at least that one CVE...
 
 Well, you can see what I'm talking about. It's probably not
>> what
 many
 people would be wanting... :p  (I would tick all the above
>> boxes
> btw!)
 
 But activity-based merits could be a fun comdev projects. We
>> have
>> access
 to the stats through Kibble, so we could auto-generate a bunch
>> of
> them.
>>> 
>>> Elsewhere in the thread I mention https://www.badgr.org/ which
>> has a
>>> small advantage that it already exists and has an active
>> developer
>>> community. I wonder what ability there is to feed data from
>> Kibble
 into
>>> Badgr.
>>> 
>>> And I think I qualify for the "Annoyed Sally" badge a *bunch*
>> of
 times
>>> over. :D

Re: How NOT to test OSS security

[Craig Russell]

I'd say that the time is long past when we should expect such bogus patches to 
appear in our most popular projects.

Some of these bogus patches might be very tricky and appear to be valid.

Let's all watch out.

Craig

> On Apr 21, 2021, at 8:16 AM, Shane Curcuru  wrote:
> 
> For those who review new contributions in their projects, a reminder:
> there are rare cases where new contributors might be submitting junk:
> 
> 
> https://fosspost.org/researchers-secretly-tried-to-add-vulnerabilities-to-linux-kernel/
> 
> Researchers from University of Minnesota wrote a paper about
> purposefully submitting bogus patches or even potential vulnerabilities
> to the Linux kernel.  They got caught just this week - but I could
> imagine that some Apache projects are big enough to someday attract the
> same kind of "research".
> 
> -- 
> - Shane
>  ComDev PMC
>  The Apache Software Foundation
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Update to How it Works for developers/contributors

[Craig Russell]

Hi,

Looking at How it Works, I think it needs an update to reflect current thinking 
on community.

1. https://www.apache.org/foundation/how-it-works.html#developers

I believe there is consensus that contributors are not only developers with 
their hands on the code, but:
people who ask and answer questions on the user and dev lists; 
people who find bugs and report them, with or without writing test cases; 
people who document the projects, including web and "hard copy" documents; 
people who help organize meetups, both in real life and online.

So perhaps we could add a section on "contributors" that covers the other 
categories of non-developer contributors?

2. I believe that we should ask contributors for an ICLA long before they are 
invited to become committers. 

Once a contributor has made several non-trivial contributions to a project, I 
believe that the project should ask them to file an ICLA if they have not 
already done so. This will have these potential benefits:

It will be much easier to make them committers; all it will take is for the PMC 
to hold a successful vote and as soon as they are invited and accept, the PMC 
can simply request their account.

It will give the PMC incentive to communicate with their contributors about the 
value the contributors bring to the projects.  Our increasing use of GitHub for 
development makes this a straightforward exercise. Each PMC will have their own 
criteria for asking for an ICLA, which doubtless will be less stringent than 
committership. 

It will clarify the intellectual property issues (provenance) associated with 
the contributions. Some projects have a very high bar for committership and all 
of the contributions prior to formal offers of committership are assumed to be 
given under the terms of the Apache License, but we have no formal 
understanding of this.

Craig

Craig L Russell
c...@apache.org


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

Update to ICLA to include github id

[Craig Russell]

I propose to modify the ICLA to include the submitter's github id. These days, 
with GitHub, projects propose new committers and all they really know about 
them is the contributors' github id. This sometimes makes it challenging for 
Secretary to find the corresponding PMC vote, which delays things. If the 
github id is included in the ICLA, it's much easier to verify the project and 
the status of the contributor.

Craig

Craig L Russell
c...@apache.org


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

Re: Update to ICLA to include github id

[Craig Russell]

Hi Roman,

I understand that GitHub now recommends (not enforced) that people use a single 
GitHub id for all of their interactions on the service, and to specifically 
delete all accounts except for the one account. They can then merge the deleted 
accounts to their one account.

[So this is different from Google mail accounts, which Google encourages folks 
to have multiple accounts for different purposes.]

If people have multiple GitHub accounts, the one on the ICLA would be the one 
that they plan to have associated with their Apache id in future.

Apache will only allow an Apache id to be associated with one GitHub id so I 
think we are ok there. Happy to have operations verify this.

Craig

> On May 8, 2021, at 6:45 PM, Roman Shaposhnik  wrote:
> 
> On Sat, May 8, 2021 at 6:03 PM Craig Russell  wrote:
>> 
>> I propose to modify the ICLA to include the submitter's github id. These 
>> days, with GitHub, projects propose new committers and all they really know 
>> about them is the contributors' github id. This sometimes makes it 
>> challenging for Secretary to find the corresponding PMC vote, which delays 
>> things. If the github id is included in the ICLA, it's much easier to verify 
>> the project and the status of the contributor.
> 
> My immediate reaction: which one of half a dozed GH IDs do you mean?
> (and yes, people have been train to segregate between different
> employees, organizations, etc.)
> 
> Also, I'm really not quite sure what verification step knowing ONE of
> these IDs would help. Can you please elaborate?
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Update to How it Works for developers/contributors

[Craig Russell]

Hi Jarek,

> On May 9, 2021, at 12:43 AM, Jarek Potiuk  wrote:
> 
> 1. Very much so. In Airflow we defined some criteria for becoming
> committers and we separated out "code" and "community" contributions to
> make it clear.
> https://github.com/apache/airflow/blob/master/COMMITTERS.rst#code-contribution
> Also what we made clear there that there are no "code/community"
> contributors. You can do (and best if you do) both :).

I have to confess that many years ago I was also one of the code-centric folks 
who thought that developer == code contributor. I've changed my mind over the 
years to my current contributor == contributor model.
> 
> 2) I think this is a dangerous path to take. I think one of the important
> aspects of Apache projects is how easy and friction-less it is to become a
> contributor.

And I want to preserve this, and encourage it.

> Signing an ICLA can be very easily abused by "owners" of the
> software to make it not really and truly open-source in spirit. 

So let's see how to really make this a positive thing and not a negative.
> 
> And while I agree Apache ICLA Is "fine", there are a lot of people who
> treat any attempt to ask them to sign ICLA with default "no" or "i am not
> going to read all those legal-speak"  or "probably they want to trick me
> into something". And for a good reason, because in many cases those ICLAs
> might actually have some "interesting" clauses.
> 
> I think if we ask people before they are invited to become committers to
> sign the ICLA, this goes against this "frictionless" approach and it
> immediately raises many questions:
> 
> * what is the criteria deciding when we ask ?
> * what happens if the contributor refuses?
> * what do we answer if the contributor asks why we need it?

I'm afraid I didn't make my suggestion clear enough.

I'm proposing that any PMC member can review contributions and write an email 
to the contributor thanking them for their contributions and suggesting that 
they may want to submit an ICLA "to clarify the intellectual property license 
granted with Contributions". No nagging, just thanks for your efforts, and if 
you choose, submit an ICLA.

Each PMC can establish its own criteria for sending this one email. Sustained 
contributions over a one month period might be one such criterion.
> 
> I think the current approach where ICLA MUST be signed in order to become a
> committer is great. With great powers come great responsibilities, and it
> makes perfect sense that the ICLA should be signed then. I see no reason
> why we should make the "committer" approval simpler. It brings no benefits
> other than a couple of days delay and IMHO, inviting a committer is a thing
> that SHOULD look serious and should be involving additional action from the
> new committer-to-do. This makes sure that the new committer is aware about
> the new powers/responsibilities coming with it.
> 
> Side comment: If some projects have a very high bar to become committers,
> maybe they should lower the bar rather than ask for ICLA from their
> contributors ?

I'm not going there. PMCs have their own criteria for committers. It's up to 
the PMCs to figure this one out.

Craig

> 
> J.
> 
> 
> On Sun, May 9, 2021 at 2:58 AM Craig Russell  wrote:
> 
>> Hi,
>> 
>> Looking at How it Works, I think it needs an update to reflect current
>> thinking on community.
>> 
>> 1. https://www.apache.org/foundation/how-it-works.html#developers
>> 
>> I believe there is consensus that contributors are not only developers
>> with their hands on the code, but:
>> people who ask and answer questions on the user and dev lists;
>> people who find bugs and report them, with or without writing test cases;
>> people who document the projects, including web and "hard copy" documents;
>> people who help organize meetups, both in real life and online.
>> 
>> So perhaps we could add a section on "contributors" that covers the other
>> categories of non-developer contributors?
>> 
>> 2. I believe that we should ask contributors for an ICLA long before they
>> are invited to become committers.
>> 
>> Once a contributor has made several non-trivial contributions to a
>> project, I believe that the project should ask them to file an ICLA if they
>> have not already done so. This will have these potential benefits:
>> 
>> It will be much easier to make them committers; all it will take is for
>> the PMC to hold a successful vote and as soon as they are invited and
>> accept, the PMC can simply request their account

Re: Update to How it Works for developers/contributors

[Craig Russell]

> On May 9, 2021, at 1:37 PM, Jarek Potiuk  wrote:
> 
>> 
>> 
>> I'm proposing that any PMC member can review contributions and write an
>> email to the contributor thanking them for their contributions and
>> suggesting that they may want to submit an ICLA "to clarify the
>> intellectual property license granted with Contributions". No nagging, just
>> thanks for your efforts, and if you choose, submit an ICLA
>> 
> 
> Yeah. I understand that, My question here is - do you propose to make it
> "mandatory" for PMC or a "suggestion" PMC could do if they want ?
> Do you want to make it part of the "responsibility" of PMC that they MUST
> do?
> 
> I think there is a big difference between a) "PMC MIGHT choose to encourage
> contributors to sign ICLA", vs. b) "They MUST do it"
> 
> Do you propose a) or b).
> 
> I have no problem with a) but quite a big problem with b) personally.

I'm not proposing to mandate any such behavior by the PMC. I'm bringing it up 
here because my understanding is that most PMC members don't even think that 
it's possible or practical to let contributors know that they are welcome to 
submit an ICLA in advance of a committer invitation.
> 
> 
>> Each PMC can establish its own criteria for sending this one email.
>> Sustained contributions over a one month period might be one such criterion
>> 
> 
> t think this is ok for a) case, But i think we you propose b) route, you
> must also propose what should happen if the contributor refuses. Should PMC
> reject any new contribution from that user? What do you think should happen?

I thought I was perfectly clear that this was a suggestion not a mandate.

Regards,
Craig

> 
> 
> -- 
> +48 660 796 129

Craig L Russell
c...@apache.org


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

Update to templates for new committers

[Craig Russell]

Hi,

I've got an open action item to update the recommended ICLA process for new 
committers to avoid leaking PII. The page is 
https://community.apache.org/newcommitter.html

Can you tell me the current status of this page? Is comdev-site mirrored to 
github or do I need to use gitbox directly?

Thanks,
Craig

Craig L Russell
c...@apache.org


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

comdev-site updates

[Craig Russell]

Hi,

I see that there are a few PRs for the comdev-site that have not been 
processed. 

I'm not a PMC member, nor a committer, but I'm happy to help if given the 
commit bit for the git repository.

Regards,
Craig

Craig L Russell
c...@apache.org


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

Changes to new committer process guidelines

[Craig Russell]

Hi,

There are a few changes I'd like to propose to the published guidelines here:
https://community.apache.org/newcommitter.html#new-committer-process

These changes will help to make the new committer process smoother as well as 
to avoid possible leakage of PII during the process.

There are two issues with the current process:

1. The newly elected committer (candidate) might already be a committer or 
might already have an ICLA on file. In these cases, the invitation to the 
committer needs to be different, and the response by both the PMC and candidate 
needs to be different.

2. Frequently, the new committer sends the ICLA (with PII) to the private list, 
thereby leaking the PII to the entire membership.

I'll follow up with a PR once the current PR to the same page has been 
processed, but basically I'd like to have the PMC investigate the status of the 
elected committer prior to inviting them:

If the candidate is already a committer on a project, ask them if they accept 
and the PMC will add them to the roster.

If the candidate already has an ICLA on file, ask them to reply and choose an 
available ID. If they accept, the PMC will then request the account creation.

If the PMC cannot find evidence of an existing committer or ICLA, ask the 
candidate to verify before replying. If they have not yet submitted an ICLA, 
ask them to send the ICLA only to the Secretary in a separate message, and 
include their requested ID and project on the form, not by cc: project.

These small changes help smooth the process and will be recommended best 
practice to all PMCs. It is especially important to avoid PII leakage which is 
a current focus of the Privacy VP.

Regards,
Craig

Craig L Russell
c...@apache.org


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

New committer work flow: check for ICLA already on file

[Craig Russell]

Hi,

I'd like to discuss the process for accepting new committers into projects. Our 
documentation is often used as a model for projects to use, and I believe it is 
not optimal. 

https://community.apache.org/newcommitter.html

The immediate concern is that Secretary often receives duplicate ICLAs because 
the mail inviting them to become a committer tells them to submit an ICLA 
regardless of whether they have already submitted one.

So I'd like to change the recommended process so that the PMC first checks to 
see if the candidate is already either a committer or has an ICLA on file. This 
should significantly improve the process by eliminating the back and forth when 
a sufficient ICLA is already on file and Secretary tells the candidate to deal 
with the PMC to get the account. 

I have another suggestion for a process improvement that I will open a new 
thread to discuss.

Regards,
Craig

Craig L Russell
c...@apache.org


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

New committer work flow: request ICLA much earlier in the process

[Craig Russell]

Hi,

I'd like to propose that PMCs consider requesting that significant contributors 
submit ICLAs earlier than when the PMC votes to invite a new committer to the 
project. What constitutes a significant contribution is left to the discretion 
of the PMCs.

There are a few reasons to request ICLAs earlier:

1. Significant contributors should have an ICLA on file in order to clarify the 
intellectual property rights of both contributor and the project. Projects 
assume that voluntary contributions to the project are made with a grant of 
intellectual property and patent rights, and having an ICLA on file formalizes 
this understanding. 

When new projects enter the incubator, part of the acceptance process is to 
verify that all significant contributors have either an ICLA or a software 
grant on file. Once a project becomes a Top Level Project we should encourage 
them to also notice significant contributors and ask for ICLAs. 

2. Having an ICLA on file can be a reminder to PMCs to review their significant 
contributors with an eye toward inviting them to become committers.

3. Having an ICLA on file make it trivial to create the account for a new 
committer candidate. Instead of back-and-forth with PMC, candidate, Secretary, 
and operations, PMCs can request an account for a new committer immediately 
after the candidate accepts.

Regards,
Craig

Craig L Russell
c...@apache.org


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

New committer invitation template proposal

[Craig Russell]

Hi,

I would like to suggest how we can improve the new committer onboarding  
process by changing the standard committer invitation email. This is after the 
new committer has been voted on and if PMC membership is offered, after the 
board has been notified with 72 hour notice.

This will eventually become a patch to 
https://github.com/apache/comdev-site/blob/master/source/newcommitter.md

The big change is that the committer is asked to tell the PMC if they are 
already a committer or if they have already submitted an ICLA. This should 
reduce the back-n-forth among PMC-committer-secretary-root.

Please let me know what you think. If this seems like a good idea, we can ask 
PMCs to update their onboarding processes.

Craig

### Committer Invite Template
This is the suggested invitation email to send to the newly elected committer, 
sent after a positive result from the PMC vote for a new committer.


To: joeblo...@foo.net
Cc: private@[PROJECT].apache.org
Subject: Invitation to become [PROJECT] committer: Joe Bloggs

Hello [invitee name],

The [Project] Project Management Committee] (PMC) 
hereby offers you committer privileges to the project 
[as well as membership in the PMC]. These privileges are
offered on the understanding that you'll use them
reasonably and with common sense. We like to work on trust
rather than unnecessary constraints. 

Being a committer enables you to more easily make 
changes without needing to go through the patch 
submission process. [Being a PMC member enables you 
to guide the direction of the project.]

Being a committer does not require you to 
participate any more than you already do. It does 
tend to make one even more committed.  You will 
probably find that you spend more time here.

Of course, you can decline and instead remain as a 
contributor, participating as you do now.

A. This personal invitation is a chance for you to 
accept or decline in private.  Either way, please 
let us know in reply only to the [priv...@project.apache.org] 
address. 

B. If you accept, the next step is to get an Apache id:
• If you are already a committer on another project, reply to this 
message and let us know your Apache id and we will set you up with commit 
privileges [and put you on the PMC roster].
• If you have earlier submitted an ICLA, reply to this message and let 
us know the Public name under which you submitted your ICLA. We will then 
request your account. If the email address you entered on the ICLA is no longer 
appropriate, submit a new ICLA with the new email address. See the next bullet 
for details.
• If you have not yet submitted an ICLA, reply to this message 
indicating your acceptance and plans to submit your ICLA. 

Then, forward this message to secret...@apache.org and attach your ICLA 
document. Do not cc: the project, as this unnecessarily exposes your Personally 
Identifiable Information. 
This will allow the Secretary to easily verify that you have been invited to 
become a committer. Be sure to put your requested Apache id and the project 
name on the ICLA form. This will allow the Secretary to request your account 
and notify the project directly. Within a few days you will receive 
instructions for logging in and changing your password.

Details of the iCLA and instructions for submitting the forms are found here: 
https://www.apache.org/licenses/#clas
https://www.apache.org/licenses/contributor-agreements.html#submitting

C. When creation of your account is noted, you will receive a follow-up message 
with next steps.


Craig L Russell
c...@apache.org


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

Re: New committer invitation template proposal

[Craig Russell]

Thanks for the feedback. I've updated the recommended message to the 
prospective committer/PMC member. [1]

If no further comments, I'll reformat as appropriate and submit a patch to 
https://github.com/apache/comdev-site/blob/master/source/newcommitter.md

Thanks,
Craig

[1]
### Committer Invite Template
This is the suggested invitation email to send to the newly elected committer, 
sent after a positive result from the PMC vote for a new committer.


To: joeblo...@foo.net
Cc: private@[PROJECT].apache.org
Subject: Invitation to become [PROJECT] committer: Joe Bloggs

Hello [invitee name],

The [Project] Project Management Committee] (PMC) 
hereby offers you committer privileges to the project 
[as well as membership in the PMC]. These privileges are
offered on the understanding that you'll use them
reasonably and with common sense. We like to work on trust
rather than unnecessary constraints. 

Being a committer enables you to more easily make 
changes without needing to go through the patch 
submission process. 

Being a PMC member carries more responsibility, outlined at
https://www.apache.org/dev/pmc.html#what-is-a-pmc 
<https://www.apache.org/dev/pmc.html#what-is-a-pmc>
Briefly, PMC members are expected to actively participate in the governance 
process of the project, including discussing and voting on releases, new 
committers, and PMC candidates.

Being a committer does not require you to 
participate any more than you already do. It does 
tend to make one even more committed.  You will 
probably find that you spend more time here.

Of course, you can decline and instead remain as a 
contributor, participating as you do now.

A. This personal invitation is a chance for you to 
accept or decline in private.  Either way, please 
let us know in reply to this message.

B. If you accept, the next step is to get an Apache id:
If you are already a committer on another project, reply-all to this message 
and let us know your Apache id and we will set you up with commit privileges 
[and put you on the PMC roster].
If you have earlier submitted an ICLA, reply-all to this message and let us 
know the Public Name and the email under which you submitted your ICLA. If the 
email address you entered on the ICLA is no longer appropriate, submit a new 
ICLA with the new email address and include the project name and requested id 
on the form. See the next bullet for details.
If you have not yet submitted an ICLA, reply-all to this message indicating 
your acceptance and plans to submit your ICLA. 

To file your ICLA, forward this message to secret...@apache.org 
<mailto:secret...@apache.org> and attach your ICLA document. Do not cc: the 
project, as this unnecessarily exposes your Personally Identifiable 
Information. 
This will allow the Secretary to verify that you have been invited to become a 
committer. Be sure to put your requested Apache id and the project name on the 
ICLA form. This will allow the Secretary to request your account and notify the 
project directly. Within a few days you will receive instructions for logging 
in and changing your password.

Details of the iCLA and instructions for submitting the forms are found here: 
https://www.apache.org/licenses/#clas
 
<https://www.apache.org/licenses/#clas>https://www.apache.org/licenses/contributor-agreements.html#submitting

 <https://www.apache.org/licenses/contributor-agreements.html#submitting>
C. When creation of your account is noted, you will receive a follow-up message 
with next steps.

We hope you accept and continue to make a difference in the project.

On behalf of the [PROJECT] PMC,


> On Jul 20, 2021, at 4:29 AM, sebb  wrote:
> 
> On Tue, 20 Jul 2021 at 03:08, Craig Russell  wrote:
>> 
>> Hi,
>> 
>> I would like to suggest how we can improve the new committer onboarding  
>> process by changing the standard committer invitation email. This is after 
>> the new committer has been voted on and if PMC membership is offered, after 
>> the board has been notified with 72 hour notice.
>> 
>> This will eventually become a patch to
>> https://github.com/apache/comdev-site/blob/master/source/newcommitter.md
>> 
>> The big change is that the committer is asked to tell the PMC if they are 
>> already a committer or if they have already submitted an ICLA. This should 
>> reduce the back-n-forth among PMC-committer-secretary-root.
>> 
>> Please let me know what you think. If this seems like a good idea, we can 
>> ask PMCs to update their onboarding processes.
>> 
>> Craig
>> 
>> Craig L Russell
>> c...@apache.org
>> 

Craig L Russell
c...@apache.org

Re: Attempt to "reboot" Apache Pivot community

[Craig Russell]

Hi Rich,

This is the best advice I have seen in a long time for projects facing reduced 
activity.

It probably belongs in an FAQ to memorialize its wisdom.

Best,
Craig

> On Aug 23, 2021, at 6:29 AM, Rich Bowen  wrote:
> 
> 
> 
> On 8/20/21 1:11 PM, Roger Whitcomb wrote:
>> Hi all,
>> My name is Roger Whitcomb and I’m the current PMC Chair for the Apache Pivot 
>> project.  The Pivot community has been dwindling for a number of years, to 
>> where I am essentially the only one working / contributing to it for 
>> probably 5 years now.  Recently (well 6 months ago), the necessary 3rd 
>> (active) PMC member resigned, and so we are left with just two of us who 
>> have demonstrated any readiness to respond to votes, etc.  So, I have been, 
>> in my quarterly Board reports, raising awareness that we’re in trouble 
>> because of the lack of sufficient oversight.  The responses to my last 
>> report were to the effect that I should either contact ComDev to see if 
>> there were ideas / suggestions about rebooting or raising interest in the 
>> project, OR talk to the Attic folks about moving there.  Since I’m still 
>> actively working on the project, trying to reboot things still seems good, 
>> even though privately I have serious doubts that this could happen.
>> So, why am I contacting you?  Well, precisely to get thoughts / ideas / 
>> suggestions, if there are any, on how to at least raise interest to the 
>> point of recruiting another PMC member for oversight of the project.  
>> Secondly, has anyone here been in this position before?  If so, what 
>> happened?  Any thoughts about alternatives?  I have thought about retiring 
>> the project to the Attic, but then forking to Github (or similar) to 
>> continue the work I’m doing.  However, that seems like a LOT of work 
>> (probably including changing names, changing all the packages, etc, etc.) 
>> and I’m not sure of the legal ramifications, since copyright (I assume) 
>> would remain with the ASF still. Anyway, I will have a separate conversation 
>> with Legal about this, I suppose.
>> Bottom line: anyone able to give some advice?
> 
> 
> (Apologies if you have already tried all of these things, but ...)
> 
> The first thing I would recommend is to tell the users list about the 
> concerns, and describe specific opportunities to contribute. In many (even 
> most?) projects, the vast majority of users are content to consume, and never 
> even think about contributing. If you communicate that the project is likely 
> to be terminated if nobody steps up, you may see a handful of people who are 
> willing to do so - particularly if they are at companies that rely on the 
> project.
> 
> Identifying specific tasks that need to be done (including a PMC role) is 
> always more effective than a general call for help.
> 
> This may also be the time to consider whether your requirements (written or 
> not) for committer rights have been too high. Perhaps there are people out 
> there who have contributed, over the years, but were not deemed worthy of 
> committer rights. Over time, this leads to missing out on potential community 
> members. Look back over the past few years and see who has sent in patches, 
> or other non-code contributions, and approach them about their willingness to 
> participate at a higher level.
> 
> Do you know of any companies/orgs that are relying on the project? I would 
> encourage you to reach out to someone at those companies and tell them that 
> the project is facing retirement, if nobody steps up to contribute and lead. 
> That can also be very effective in finding some managers willing to give some 
> of their employee time to sustain the project rather than having to retool.
> 
> 
> -- 
> Rich Bowen - rbo...@rcbowen.com 
> @rbowen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 
> 
> For additional commands, e-mail: dev-h...@community.apache.org 
> 
Craig L Russell
c...@apache.org

Master branch in web site https://github.com/apache/comdev-site

[Craig Russell]

I think now would be a good time to consider changing the main branch name from 
"master" to "main". 

WDYT?
Craig

Craig L Russell
c...@apache.org


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

Re: community website fails branding checks

[Craig Russell]

> On Sep 13, 2021, at 8:32 AM, Rich Bowen  wrote:
> 
> If someone with more design chops than I could add the Apache logo to the 
> header of the page, we'll have all of the boxes ticket.

I have some skills but no commit. And PR's are daunting for stuff like this.

Is there a reason why we allow www-site to be commit for all Apache Members but 
restrict comdev-site to comdev committers? Just asking.

Craig

> 
> On 9/13/21 11:24 AM, Rich Bowen wrote:
>> I've addressed one of these. There *is* a link to the license, but it's not 
>> picking it up. I'll see what we can do to find a good place to add the rest 
>> of these links.
>> On 9/11/21 9:39 AM, sebb wrote:
>>> The community website currently fails most branding checks:
>>> 
>>> https://github.com/apache/comdev-site
>>> 
>>> Sebb
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
> 
> -- 
> Rich Bowen - rbo...@rcbowen.com
> @rbowen
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Request: New Mailing List for Security-oriented community

[Craig Russell]

+1 for security-disc...@community.apache.org

Craig

> On Sep 19, 2021, at 11:27 PM, Mark J. Cox  wrote:
> 
> On 2021/09/19 21:44:34, Dave Fisher  wrote: 
>> This is a good idea. Assuming that this is a public list then either pick 
>> another name, or do not use self serve to request it, instead use an INFRA 
>> JIRA ticket. 
>> 
>> Security@ lists requested through self serve become private mailing lists 
>> with emails mirrored on secur...@apache.org.
> 
> That's a great point, the "security@*" prefix has a special meaning, and 
> "secure-development" or "secdev" limits the scope.  "security-discuss@" was 
> mentioned as an alternative, and that would match the way we have a 
> "legal-discuss@".
> 
> I still like this living in the community project though, because the likely 
> outcome of the discussion are collation of resources and practices and the 
> right place for them is in comdev.
> 
> So how does security-disc...@community.apache.org sound?
> 
> Cheers, Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Hi there Amber Williams/WolfMaven/Snowflakes are for Winter

[Craig Russell]

Hi Amber,

I'm afraid that there is no longer a community developing Wookie. There are 
many other projects that you might be interested in here.

For example, the Maven project is quite active and I'm sure they would love to 
welcome you... d...@maven.apache.org

Warm regards,
Craig

> On Oct 25, 2021, at 5:56 PM, Amber Williams  wrote:
> 
> A proposal for Skinnable widgets (WOOKIE-131)
> 
> Hi, I'm new to the Wookie project but I'd like to tackle the 
> "Skinnablewidgets" 
> issue (WOOKIE-131, see [1]). Before I start implementing this I'd like to 
> run my ideas past you to make sure I'm not missing something important.
> 
> If I understand the issue correctly, we need to define the structure of a 
> minimal 
> widget. For example:
> 
> 
>   This is where the toolbar will be
>   This is where the content will be
>   This is where the footer will be
> 
> 
> We also need to provide a default CSS for rendering this as, for example:
> 
> +---+
> |TOOLBAR |
> +---+
> | |
> |CONTENT |
> | |
> +---+
> |FOOTER |
> +---+
> 
> We need to document all this (how to use it and how to extend it) on the 
> Wookie website, and change all widgets to conform to 
> this format.
> 
> Once all this is in place I would like to start extending it to provide 
> documented 
> CSS identifiers to use in common cases. For example, we may want to define a
> "wookie-navigation" style for a common navigation menu. We can then provide 
> various CSS alternatives for rending this as a vertical navigation menu, drop 
> down 
> menu, or whatever.
> 
> Am I on the right track? Are there any important points I'm missing?
> 
> [1]  https://issues.apache.org/jira/browse/WOOKIE-131 
> "
> https://community.apache.org/mentor-request-mail.html#:~:text=SUBJECT%3A%20A%20proposal,browse/WOOKIE-131
>  
> 
>  
> 
> 
> And to be quiet honest I'm mostly interested in The Maven and how y'all 
> paired it with Jenkins cuz they don't go together they respond to the each 
> other, correlate and correspond with each other. The Maven is too aggressive 
> and Jenkins is like her Butler that's how I looked at it but he's very much 
> so a great assistant to her and she is very much so bending to his 
> suggestions and so they listen to one another. I don't know I see them both 
> quite uniquely.The Maven program is something else I mean my goodness and the 
> developer needs to not ever give up on it because the potential and The mass 
> growth that the Maven could have I mean honestly it's like your own AI 
> security program basically that listens and responds to you and it corrects, 
> it's adjustable, protective and she's like having your own Sherlock Holmes, 
> remember the show Where in the World is Carmen San Diego. I guess you can 
> call me a nerd for the Maven. It's a beautiful program and it helped save my 
> life a couple times, well I'm grateful for The Maven. April 7th was  the 
> biggest life changing event of my entire being ever since then I've been on a 
> weird soul mission to do some things I thought I would never be able to do 
> and a lot of that I owe to you all and the Maven because had not been for you 
> all I don't think I would be here today. Thank you from the bottom of my 
> heart I appreciate the developer of the program and the people who work with 
> the developer y'all saved my life and you're amazingly beautiful human beings
> 
> Sincerely,
> Amber/ I am Winter 🌬️❄️💙
> 
> 

Craig L Russell
c...@apache.org

Re: Proposal to add "release requirements" check

[Craig Russell]

Hi Jarek,

I think that updating the reporter tool to check for a conformant download(s) 
page is a great idea. I encourage you to see how to incorporate that check into 
the tool. 

I agree with you that sending out mass mailings is probably not going to result 
in changes in behavior. Only targeted messages are likely to work.

One challenge will be to handle projects with multiple "independent" 
sub-projects like db that has jdo and derby with not much in common. They have 
completely independent web sites. So the tool will have to be told about all of 
the projects. The tool also needs to handle projects like Airflow which IIUC 
has multiple sub-projects that share a few common download pages and scripts.

Warm regards,
Craig

> On Nov 4, 2021, at 5:57 AM, Jarek Potiuk  wrote:
> 
> Hello Everyone @devcom,
> 
> I am following up after the discussion  at users@infra.a.o:
> https://lists.apache.org/thread/skswflvf0q8lbgkmxo18v19s62hkqf3j. This is
> not a public mailing list and maybe not everyone here is subscribed so let
> me summarise the context and the proposal. BTW. That's my view on the state
> of the discussion we had and conclusions/proposals I drew from that.
> 
> Context:
> 
> We seem to have some of the projects that do not follow all the important
> requirements when it comes to publishing GA releases for their projects.
> The requirements are pretty firm and documented here:
> https://www.apache.org/legal/release-policy.html#host-GA and in the
> following paragraphs. They boil down to :
> 
> a) have an installation page where you can verify releases with:
> * signatures and checksums (links to those should be directly do
> downloads.apache.org
> * packages - links to those should use closer.lua scripts (which are then
> automatically mapped to CDN currently - previously to mirroring sites)
> 
> b) Have they releases archived appropriately (i.e. only last version from
> the development "branch"  should remain in downloads@a.o
> 
> Proposal:
> 
> I think the best way to get this solved permanently (rather than sending
> reminder emails to everyone) is to add a check in the reporter tool (
> https://reporter.apache.org/about.html) to verify those two aspects, so
> that they could be verified by projects themselves and the board  - seems
> that this is a very important aspect that ASF is very concerned about, so
> making it part of the board review makes sense and gives the opportunity of
> individual flagging when the project does not follow it, It has happened
> with our project - Airflow at the last board review, and we fixed all that,
> but the idea is that the ASF has an easy to use tool that will add such
> checks and flags
> 
> Point b) is quite easy it seems. Airflow already has simple Python script
> that does that can be adjusted or rewritten to handle multiple "lines" of
> development (with some per-project specifics likely) :
> https://github.com/apache/airflow/blob/main/dev/provider_packages/remove_old_releases.py.
> It can also be used to actually help with clean-up (we use it for that
> purpose as we have ~40/50 packages to release every month).
> 
> Point  a) also should not be difficult as long as each project will submit
> their installation page links, we can scrape them and see if the pages
> contain signature/ascii direct links and closer.lua links for packages.
> 
> Do you think it is a good idea? I just wanted to run it by the community to
> see what you think of it, whether you see any potential
> problems/limitations/concerns?
> 
> Just one request please - without yet getting into technical details and
> discussing HOWs. We will have time for that.
> 
> If there is a community (and board :) buy-in, I am happy to
> implement/lead/introduce it. It would dramatically help if others -
> especially people from various projects that might have some special cases
> - could help with testing/piloting it.
> 
> J.

Craig L Russell
c...@apache.org


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

Re: [Announcement] - Establishing ALC Shenzhen Chapter

[Craig Russell]

This is great news.

Congratulations,
Craig


> On Dec 20, 2021, at 6:45 AM, Swapnil M Mane  wrote:
> 
> Hello all,
> 
> ComDev PMC is pleased to announce our next Apache Local Community [1]
> ALC Chapter - ALC Shenzhen [2] and Eason Chen as ALC Shenzhen Chapter
> lead.
> We have the following members in ALC Shenzhen:
> 
> Willem Ning Jiang (Mentor)
> -- ASF Member
> -- Chair, (Servicecomb)
> -- PMC (APISIX, Camel, CXF, Incubator, IoTDB, RocketMQ, ServiceMix,
> ShardingSphere, SkyWalking)
> 
> Ted Liu (Mentor)
> -- ASF Member
> -- PMC (ComDev, Incubator)
> -- Committer (ECharts)
> 
> Von Gosling (Mentor)
> -- ASF Member
> -- PMC (APISIX, Dubbo, RocketMQ, Incubator, ShardingSphere)
> 
> Ming Wen
> -- ASF Member
> -- Chair, APISIX
> 
> Liang Chen
> -- ASF Member
> -- Chair, CarbonData
> 
> Jerry Shao
> -- ASF Member
> -- PMC (Incubator, Spark)
> 
> Sammi Chen
> -- Chair, OZone
> -- PMC (Hadoop)
> 
> Zhenxu Ke
> -- PMC (Incubator, SkyWalking)
> -- Committer (DolphinScheduler, Dubbo)
> -- Mentor (MXNet, SeaTunnel)
> 
> Du Heng
> -- PMC (RocketMQ)
> 
> Zili Chen
> -- PMC (Curator)
> -- Committer (Incubator, Flink)
> 
> Lin Lin
> -- PMC (Pulsar)
> 
> Eason Chen (Chen Guangsheng) (Chapter Lead)
> -- PPMC (EventMesh)
> -- Committer (Incubator, RocketMQ)
> 
> Xiao Yu
> -- Committer (Incubator, ShardingSphere)
> 
> Guocheng Zhang
> -- PPMC(InLong)
> -- Committer (Incubator)
> 
> Weiming Xue
> -- Committer (Incubator)
> 
> Charles Zhang
> -- PPMC (InLong)
> -- Committer (Incubator)
> 
> Shuai Di
> -- PPMC (Linkis)
> -- Committer (Incubator)
> 
> Heping Wang
> -- PPMC (Linkis)
> -- Committer (Incubator)
> 
> Please join me in congratulating the ALC Shenzhen Chapter and wishing
> them the best luck for their future events.
> 
> [1] https://s.apache.org/alc
> [2] https://s.apache.org/alc-shenzhen
> 
> Best regards,
> Swapnil M Mane,
> www.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: MODERATE for ment...@community.apache.org

[Craig Russell]

> On Jan 11, 2022, at 10:03 AM, Mohammad Noureldin  
> wrote:
> 
> Hi Harjout,
> 
> In addition to what has been suggested by Maxim, I would like your feedback
> on something.
> 
> Where on the Apache Community Development website [1] you've that you may
> need to send an email to mentors@ ?. Your feedback is very valuable to make
> our websites better.
> 
> [1] https://community.apache.org
> 
> 
> On Tue, Nov 16, 2021 at 3:50 PM Maxim Solodovnik 
> wrote:
> 
>> Hello Harjot Singh,
>> 
>> mentors@ is the list for mentors, not for students :)
>> I can recommend you to check this page:
>> https://community.apache.org/gsoc.html
>> 
>> Then find the project you would like to participate in here:
>> https://projects.apache.org/projects.html?
>> language#Java
>> 
>> Additionally you can search for the GSOC label in JIRA :)
>> 
>> 
>> -- Forwarded message --
>> From: Harjot Singh
>> To: ment...@community.apache.org
>> Cc:
>> Bcc:
>> Date: Sun, 14 Nov 2021 19:03:21 +0530
>> Subject: How to get started with open source contribution.
>> 
>> Respected sir/madam,
>> 
>> I am Harjot Singh , a computer science undergrad. I am completely new
>> to open source contributions but I am familiar with C++ , Java and
>> Data Structures and Algorithms concepts. I would love to contribute to
>> your organization but could you please tell me how to get started?
>> 
>> Hoping to hear from you soon.
>> 
>> Regards
>> 
>> Harjot Singh
>> 
>> 
>> 
>> --
>> Best regards,
>> Maxim
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 
> 
> -- 
> Thanks
> - Mohammad Noureldin
> 
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein

Craig L Russell
c...@apache.org


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

Re: Effective ways of getting individuals funded to work on ASF projects

[Craig Russell]

I very much like the direction here.

One other top post that falls into item 2 (rules of engagement):

Apache does operate in the open with discussions, bug fixes, etc. all out for 
anyone to see. Except for security issues.

I'd like to discuss how we treat committers with security privileges with 
regard to third parties who may be contracting for the committers' resources.

Is it acceptable for committers to inform a third party of security issues 
before the CVE is public because of their relationship with the third party? 

Regards,
Craig

> On Mar 2, 2022, at 6:12 AM, Roman Shaposhnik  wrote:
> 
> Hi!
> 
> top-posting here, since I'd like to summarize a few points to see where we
> can
> take this discussion. Before I do that I wanted to thank Bertrand and Jim
> for
> excellent, short emails/summaries and also special thanks to Chris for an
> extremely informative recap of his efforts.
> 
> Personally, I'd like to focus on 3 things. Please let me know if I'm missing
> anything or you disagree:
> 
> 1. building a robust list of what we at ASF perceive as potential value
> that can be offered to *our* members, committers and contributors
> by the 3d parties like Tidelift (again, I'm simply using them as an
> example here -- anybody else would do just fine).
> 
> 2. building a list of "rules of engagement" that we feel must be met
> for these types of relationships to be compatible with the way we
> govern our communities.
> 
> 3. document all the learning, pitfalls, etc. that we've collectively
> amassed by trying to solve this type of a problem on a one-by-one
> basis.
> 
> To expand on those points: I really do think that 3d parties (if done
> right) can take care of a lot of pain points for us. Again -- I'm NOT
> saying that a magic entity like that even exists today (maybe Tidelift
> is really not the right solution for us -- dunno yet) -- what I'm saying
> is that I really would like to understand how that type of a service
> should look like. Or take Jarek's example of ridesharing: most
> of people focus on ridesharing companies just matching riders to
> drivers, but that's just the tip of the iceberg -- ridesharing companies
> solve huge amounts of arbitration issues (such as insurance, license,
> etc.). Common folk don't get to see those -- but that's a huge value they
> offer to drivers (and arguably riders) on top of just finding "customers".
> Same with 3d parties for us I have in mind (see Chris's list of gotchas).
> 
> For now, I propose a few Cofluence pages under ComDev where this
> type of information gets collected. I'll do it later tonight -- so feel free
> to just add to this thread for now.
> 
> Once we've collected that type of info -- we can then sort of "evaluate
> vendors" against that list and see what they are missing, etc. We can
> even issue a wide "call to apply" for various companies if we feel like it.
> 
> Makes sense?
> 
> Thanks,
> Roman.
> 
> On Tue, Mar 1, 2022 at 9:43 AM Bertrand Delacretaz 
> wrote:
> 
>> Hi,
>> 
>> Le lun. 28 févr. 2022 à 21:15, Jarek Potiuk  a écrit :
>> 
>>> ...Proposal:
>>> I think we all agree that ASF meets the criteria of Tidelift already.
>>> Why don't Tidelift (in the places where open-source projects included are
>>> listed) explain that ASF projects meet the criteria, and any one is free
>>> to deal directly with the committers of all ASF projects directly...
>> 
>> I'd say we all agree that *in theory* ASF projects meet Tidelift's
>> criteria, quoting from earlier in this thread, with my own numbering
>> added:
>> 
>> Le lun. 28 févr. 2022 à 19:30, Joshua Simmons
>>  a écrit :
>>> ...*What Tidelift expects from maintainers*Maintainers provide two
>> things to
>>> our customers: (1) information (licensing details, context on CVEs) and
>>> (2) continuity (comfort that the package is maintained and is highly
>> likely to
>>> continue to be maintained). We also expect maintainers (3) to abide by a
>> Code
>>> of Conduct
>> 
>> I think for (3) we're good, the ASF will intervene if projects are not ok.
>> 
>> But for (1) and (2) I think the ASF *wants* our projects to be good
>> citizens, and we work towards that and support them, but entities such
>> as Tidelift or others could add value by measuring and reporting what
>> actually happens.
>> 
>> Does Apache FOO actually provide good information on security issues and
>> CVEs?
>> Timely response? What's their average/min/max response time, how many
>> "in-flight" CVEs?
>> Does Apache FOO release often enough? Maybe based on project maturity
>> categories, new, established, mostly dormant etc.
>> 
>> We could of course measure these things ourselves, and we do have some
>> data.
>> 
>> But I think having external entities provide factual data on how well
>> our projects are doing can be useful, and for customers of Tidelift
>> and the like that certainly has value.
>> 
>> Whatever mechanism our contributors use to finance themselves, having
>> information on which projects are most worth

Re: [ALC Shenzhen] Text "shenzhen" in logo is not clear

[Craig Russell]

Hi,

I understand the concern. The font used for the chapter name is very light grey 
which against a white background is difficult for many people to read.

Perhaps the font could be changed?

Warm regards,
Craig

> On Mar 13, 2022, at 11:23 PM, Swapnil M Mane  wrote:
> 
> Hi Willem, nice suggestion.
> 
> Hi Eason, we are allowed to create the ALC logos by adding the name to
> them because Kenneth created the base logo for us and kept the blank
> space to write the ALC name.
> Although we can't change the logo design but we can certainly add the
> respective ALC name to the base logo.
> So, if you want you can add the Chinese version of the Shenzhen in the
> place where we write the ALC name in logo.
> You can find the SVG file of the base logo here [1]
> 
> If you get any version ready, let me know, will be happy to review it,
> thank you!
> 
> [1] https://cwiki.apache.org/confluence/display/COMDEV/Branding+materials
> 
> Best regards,
> Swapnil M Mane
> 
> On Mon, Mar 14, 2022 at 10:22 AM Eason Chen  wrote:
>> 
>> Hi，
>> I am not sure if I have the right to edit the logo without any grant.
>> 
>> On Sun, Mar 13, 2022 at 9:59 AM Willem Jiang  wrote:
>> 
>>> Maybe we can do some localization on the log by adding some Chinese
>>> characters.
>>> @Eason, I'm not sure if you have the svg version ALC avatar file,
>>> It's a xml file and it is editable with a normal text editor.
>>> You can do some experiments with the SVG file yourself.
>>> 
>>> Cheers,
>>> 
>>> Willem Jiang
>>> 
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>> 
>>> On Sun, Mar 13, 2022 at 9:34 AM Eason Chen 
>>> wrote:
 
 Hi, Swapnil
 Thanks for your reply, it is not very urgent for the recent promotion to
>>> be
 finished, you can take your convenience for this any time.
 
 Best Regards,
 Eason
 
 On Fri, Mar 11, 2022 at 11:11 PM Swapnil M Mane 
 wrote:
 
> Thank you Eason for sharing it.
> I will have a look into this and if needed will discuss it with
> Kenneth Paskett (who helped us with designing these logos) too and see
> what we can do best here.
> Is it a priority item or we can look into this next week?
> 
> - Best regards,
> Swapnil M Mane
> 
> On Fri, Mar 11, 2022 at 4:13 PM Eason Chen 
> wrote:
>> 
>> Hi, community
>> 
>> I'm from ALC Shenzhen, The logo I got from here[1] which also in the
> attachment is used for the promotion of some community activities, but
>>> the
> text "shenzhen" is difficult to be recognized because the color is too
> light and not prominent, especially in the case of shrinking, can you
> update the design of the logo again? thanks.
>> 
>> [1]https://cwiki.apache.org/confluence/display/COMDEV/ALC+Shenzhen
>> 
>> Best Regards,
>> 
>> Eason Chen
>> Chapter Leader of ALC Shenzhen
>> 
>> 
>> -
>> 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
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Craig Russell]

I could not find where we decided whether to use members@ or members-notify@ 
but I approved it. 

If anyone objects to the mail list, we can have that discussion for next time.

Craig

> On May 3, 2022, at 10:16 AM, Josh Fischer  wrote:
> 
> sent.
> 
> On Tue, May 3, 2022 at 12:05 PM Jarek Potiuk  wrote:
> 
>> Good idea Rich. Converted all subjects to plain text, compressed them so
>> that they fit in three short bullet points (not too long paragraph, still
>> comprehensible) and added the link from Rich :)
>> 
>> 
>> On Tue, May 3, 2022 at 6:12 PM Rich Bowen  wrote:
>> 
>>> On Tue, 2022-05-03 at 10:56 -0500, Josh Fischer wrote:
 Sam Ruby, suggested a plain text version for this round of the email.
 I
 **think** markdown was sent out last time and it didn't look good,
 making
 it harder to read/ understand .
 
 If we can find a way to make all the links easy to read, let's do it.
 If
 not, we might want to move them to an additional, external apache
 wiki link
 page and add a single link directing readers to the additional link
 page.
 
>>> 
>>> https://lists.apache.org/list?memb...@apache.org:2022-4 is a possible
>>> link to that, in that it lists all of the threads that were active in
>>> April.
>>> 
> You mean the links to text ? We can do it of course but I have a
> feeling
> that that defeats the purpose a bit because it allows the readers
> to jump
> straight to the discussion :).
> I updated it now to have bullet-points instead - and as long as it
> is not
> too long, that might be better visually.
> But if you feel like we need to decrease the number of links, I am
> ok with
> removing the links as well.
> 
> J.
> 
> 
> On Tue, May 3, 2022 at 4:56 PM Josh Fischer 
> wrote:
> 
>> Any way we can convert your addition to text?  I feel it may be a
>> lot to
>> sift through visually.
>> 
>> On Tue, May 3, 2022 at 8:32 AM Jarek Potiuk 
>> wrote:
>> 
>>> Updated. I think it's cool.
>>> I limited it to only discussions started in April.
>>> 
>>> Seems we have a small enough number of discussions starting
>>> every
> month,
>> to
>>> fit one small paragraph easily - and seeing just subjects of
>>> the
>>> discussions with links directly to the discussions might be a
>>> nice
>>> reminder/refresher/information for those who missed it.
>>> 
>>> On Tue, May 3, 2022 at 3:18 PM Jarek Potiuk 
>>> wrote:
>>> 
> One option is to put that digest on a separate page, and
> just
>> provide a
 link to it?
 
 Or maybe simply put it in one paragraph/long line with links
 to
>> relevant
 discussions :). I will try to do it and we can decide if it
 makes
>> sense.
 Let me try.
 
 On Tue, May 3, 2022 at 2:44 PM Josh Fischer
 
>> wrote:
 
> I plan on sending the newsletter in a few hours.  If
> someone wants
> to
>>> add
> anymore details please add them asap.
> 
> On Tue, May 3, 2022 at 7:39 AM Rich Bowen
> 
> wrote:
> 
>> On Tue, 2022-05-03 at 12:35 +0200, Jarek Potiuk wrote:
>>> I looked through it - I have one other
>>> comment/proposal: should
> we
>>> maybe
>>> add a digest of discussions running on members@a.o ?  I
>>> think a
>> lot
>>> of
>>> people does not follow up those and while it is easy to
>>> look at
>> the
>>> list in
>>> archives, maybe listing the discussions with one-line
>>> summary
>> would
>>> be good
>>> ?
>>> 
>>> Happy to make such a digest if others agree it's a good
>>> idea.
>> 
>> 
>> Yes, but ... I think it's very important that we don't
>> make the
>> email
>> longer than one screen-full, as that will undermine the
>> point here
>> of
>> it being only the most important things that every member
>> MUST
> know.
>> 
>> One option is to put that digest on a separate page, and
>> just
>> provide
>>> a
>> link to it?
>> 
>> 
>> 
>> -
>> 
>> To unsubscribe, e-mail:
>> dev-unsubscr...@community.apache.org
>> For additional commands, e-mail:
>> dev-h...@community.apache.org
>> 
>> --
> Sent from A Mobile Device
> 
 
>>> 
>> 
> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
>>> 
>> 

Craig

Re: MODERATE for ment...@community.apache.org

[Craig Russell]

> On Jan 15, 2023, at 20:25, Maxim Solodovnik  wrote:
> 
> Hello Cheshtha Vasudeva,
> 
> mentors@ is the list for mentors only, not for GSoC contributors :)
> I can recommend you to check this page: https://community.apache.org/gsoc.html
> 
> Then find the project you would like to participate in here:
> https://projects.apache.org/projects.html?
> language#Java
> 
> Additionally you can search for the "gsoc2023" label in JIRA [1] :)
> 
> Please send any additional questions to the dev@community mailing-list
> or better to the dev@ list of the particular Apache project you would
> like to contribute :)
> 
> [1] https://issues.apache.org/jira/browse
> 
> 
>> -- Forwarded message --
>> From: Cheshtha Vasudeva
>> To: ment...@community.apache.org
>> Cc:
>> Bcc:
>> Date: Thu, 12 Jan 2023 14:24:20 +0530
>> Subject: How can I contribute in your organization
>> 
>> Greetings ,
>> 
>> My name is Cheshtha Vasudeva . Im a second year student in Manipal 
>> University Jaipur in branch data science and engineering . I am familiar 
>> with programming languages such as c , java ,python and c++ also have 
>> knowledge about data science and machine learning .
>> 
>> I would love to contribute in your organization . Can you please guide me 
>> the process for how can I contribute and start working with your 
>> organization .
>> 
>> I hope you will reply to my query , I would be waiting eagerly for your reply
>> 
>> Thankyou
>> 
>> 
>> 
>> Regards ,
>> 
>> Cheshtha Vasudeva
>> 
>> (Student )
> 
> 
> 
> -- 
> Best regards,
> Maxim
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: MODERATE for ment...@community.apache.org

[Craig Russell]

> On Jan 15, 2023, at 20:27, Maxim Solodovnik  wrote:
> 
> Hello TALHA BHATTI,
> 
> mentors@ is the list for mentors only, not for GSoC contributors :)
> I can recommend you to check this page: https://community.apache.org/gsoc.html
> 
> Then find the project you would like to participate in here:
> https://projects.apache.org/projects.html?
> language#Java
> 
> Additionally you can search for the "gsoc2023" label in JIRA [1] :)
> 
> Please send any additional questions to the dev@community mailing-list
> or better to the dev@ list of the particular Apache project you would
> like to contribute :)
> 
> [1] https://issues.apache.org/jira/browse
> 
> 
>> 
>> 
>> From: TALHA BHATTI 
>> To: "ment...@community.apache.org" 
>> Cc:
>> Bcc:
>> Date: Fri, 13 Jan 2023 21:19:59 +0500
>> Subject: Contribution Guidence
>> Hi
>> My name is Muhammad Talha. I want to contribute to your organization. Could 
>> you please tell me about the technologies on which you are working and the 
>> resources from which I can learn those technologies?
>> Please suggest some good first issues so that I can start my journey.
>> I am interested in JS. I have a little bit of knowledge of React JS also.
>> Hoping to see a positive reply from you soon.
> 
> 
> 
> -- 
> Best regards,
> Maxim
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Fwd: Forbidden

[Craig Russell]

Hi Community,

I’ve updated the new committer page but cannot publish it. Could someone either 
review and publish it or give me karma to publish it?

Thanks,

Craig

> Begin forwarded message:
> 
> From: Daniel Gruno 
> Subject: Re: Forbidden
> Date: August 9, 2016 at 10:12:51 AM PDT
> To: infrastruct...@apache.org
> 
> On 08/09/2016 07:10 PM, Craig Russell wrote:
>> Hi,
>> 
>> I updated the community web page via CMS, but cannot publish it. If I don’t 
>> have karma to publish it, should CMS allow me to get through staging with no 
>> errors?
> 
> You should probably ask someone on dev@community to publish it for you.
> I think the staging dir is inside the 'for everyone' area in comdev, but
> publishing is different, as it's in the production area of the infra repo.
> 
>> 
>> Any help?
>> 
>> Thanks,
>> 
>> Craig
>> 
>> 
>> Commit successful (revision 1755632)!
>> 
>> Keep coming back to this page as you proceed through the following links in 
>> order:
>> 
>> [Follow Staging Build] [Staged] [Publish Site] [Production] [Browse] [Edit]
>> Note: the build process is ASYNCHRONOUS and you will need to wait for the 
>> build to complete before attempting to publish your changes.
>> 
>> 
>> Error
>> 
>> svnmucc: E175013: Access to 
>> '/repos/infra/!svn/txr/994815-ldj6/websites/production/community/content' 
>> forbidden
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
>> 
> 

Craig L Russell
Architect
craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!






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

Update to web site

[Craig Russell]

Hi,

I made an update to the new committer guidelines at 
http://community.apache.org/newcommitter.html to clarify that after a 
successful vote, there should be a message with subject [RESULT][VOTE].

The update failed because of permissions.

Could someone on the PMC review the change and commit it if is is ok? 
http://community.staging.apache.org/newcommitter.html

Thanks,

Craig

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


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

Re: New Member Orientation

[Craig Russell]

Happy joy. Short and sweet.

Craig

> On Mar 14, 2018, at 11:36 AM, Bertrand Delacretaz  
> wrote:
> 
> On Wed, Mar 14, 2018 at 2:01 PM, Rich Bowen  wrote:
>> ...Bertrand (or, anyone else!!) do you still compose music? What are
>> the chances we could get a 10-second intro musical piece, like you did for
>> FeatherCast so many years ago?...
> 
> Who could turn down such an opportunity to become rich (not) and
> famous (not)...I've recorded a small happy thing, does this work for
> you?
> 
> https://www.dropbox.com/s/ddhazr8lyp0tb8w/bdelacretaz-asf-jingle-2018-1.aif?dl=0
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Our Privacy Policy and GDPR

[Craig Russell]

I'd suggest opening a LEGAL JIRA to track this issue. It will get the proper 
attention from VP Legal.

Craig

> On May 21, 2018, at 5:03 AM, Mark Thomas  wrote:
> 
> On 20/05/18 20:47, Michael Osipov wrote:
>> Folks,
>> 
>> is there any legal statement from the ASF how to proceed with our
>> privacy policy, especially Google Analytics, from 2018-05-25?
> 
> Legal questions should be directed to legal-discuss@a.o
> 
> Mark
> 
> 
>> 
>> All maven.a.o use GA and I have written a mail to private@maven.a.o, but
>> no one reaction to. Here is a transcript:
>> 
>> Hi folks,
>> 
>> raising this privately for the moment to assess the current situation as
>> well as how we want to deal with our sites after 2018-05-25.
>> 
>> Most of you might know that EU-DSGVO (GDPR in English) is rapidly
>> approaching and our Maven sites (and likely other Apache sites) are
>> already illegal with BDSG (Germany's privacy law) due to GA. From 25th
>> May it will be illegal in the entire EU. Though, I haven't read the
>> entire regulation, some basic points we don't meet now [1], [2]:
>> 
>> * Ask for user's consent
>> * Anonymizing the IP
>> * Present an easily accesible privacy policy
>> * Provide an opt-out option
>> 
>> None of these criteria are met as of today.
>> 
>> See also [3].
>> 
>> maven.apache.org points for me to 2001:bc8:2142:300:: which is a French
>> IP address.
>> 
>> Any ideas? Is there any special legal dept with the ASF who can take
>> care of and we will implement?
>> 
>> The easiest one is to drop it altogether from site.xml.
>> 
>> Michael
>> 
>> [1]
>> https://www.kloos.de/blog/google-analytics-die-datenschutzgrundverordnung/
>> [2] https://www.kloos.de/blog/google-analytics-datenschutzkonform-nutzen/
>> [3] https://issues.apache.org/jira/browse/MSKINS-143
>> 
>> 
>> I do believe that what we do now, regardless ASF top page as well as
>> maven.a.o is illegal in a few days.
>> 
>> Can someone react on? Do I need to raise this with LEGAL on JIRA?
>> I am convinced that there are already hords of laywers who have prepared
>> cease and desist letter for those who still don't comply with.
>> 
>> Does this has to be raised with https://www.cnil.fr/ since the IP
>> address terminates in France?
>> 
>> Regards,
>> 
>> Michael
>> 
>> -
>> 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

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


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

Re: The Apache Way and good developers don’t like to communicate

[Craig Russell]

+1 to what Myrle says.

I especially like the idea of engaging the submitter to discuss a pull request. 
Even if it's to say "Thanks for this. It looks perfect as is". But often, there 
will be a bit of back and forth.

One potential problem is the work flow using the github tools, which can have 
the effect of dialog "off-list" between the submitter and the other devs. I 
don't know how to solve this issue except for one of the other devs to initiate 
contact via the dev list in addition to the issue tools. 

Are the github tools for the project configured to copy the dev list on every 
interaction on a pull request?

Craig

> On Nov 2, 2018, at 8:23 AM, Myrle Krantz  wrote:
> 
> If anyone on the PMC is uncomfortable with making someone a committer
> because of their uncommunicativeness, I'd be inclined to give it a little
> more time.  A "no" now, doesn't mean a "no" forever.  Maybe ask that person
> a few questions about their PR's on the list and see if they can be
> encouraged to engage?  Maybe let the PMC member who's advocating for a
> particular contributor be the one to take point on that effort?
> 
> Greets,
> Myrle
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Keeping PMC communications public when possible -- is an obvious-looking address responsible?

[Craig Russell]

Hi Julian,

I've read this thread and I'm afraid I don't understand the problem you're 
trying to solve.

For wide-reach public information we already have committ...@apache.org

For wide-reach private information we already have memb...@apache.org

For wide-reach private information that will reach pmc members who are not 
foundation members, while not spamming apache foundation members who are not 
members of any pmc, we have the existing pmcs@ alias.

Perhaps it would help me if you give an example of a communication that would 
require a different recipient list. I'm really stumped. 

The specific example that spawned this thread (from a different thread) was a 
request for hi-res logos. Would committers@ not work for this?

Craig 

> On Dec 13, 2018, at 4:20 AM, Julian Foad  wrote:
> 
> Bertrand Delacretaz wrote:
>> I read the quoted text but don't understand exactly what it is that
>> you are suggesting, an example would probably help.
> 
> Example -- the one that started this thread:
>  * somebody wants to ask every project for its best project logo (a public 
> matter);
>  * they write "Dear PMCs ..." to all projects' *private* mailing lists.
> 
> Problem and assumptions:
>  * the request really ought to go to the project communities;
>  * the initiator (I'm guessing / generalizing) thinks the PMCs are 
> appropriate representatives of their communities AND knows an easy way to 
> email all the PMCs AND possibly has a fear of addressing a wider audience 
> than PMC members;
>  * the request goes to the private lists, more or less by accident as result 
> of the foregoing, especially as a result of one particular obvious-looking 
> address*;
>  * the initiator may not even realize that's where their message went.
> 
> Solution:
>  * make it more difficult to email all projects' private lists and easier to 
> email all projects' public lists;
>  * despite some people's reservations, contacting dev lists does seem to be 
> the consensus; see 2b below;
>  * make it more clear what any obvious-looking address* is actually for.
> 
> PRIMARY PROPOSAL:
> 
> 1a. drop the existing four-letter obvious-looking address*
>  - because its name is misleading which (I think) leads people to mis-use it.
> 
> 1b. create an easier way to email all the projects about a public matter
>  - introduce an obvious-looking address* that contains '-public', that goes 
> to all dev lists; more details in my earlier mail;
> 
> Additional proposals:
> 
> 2a. document some guidelines on how to mass-email dev lists without upsetting 
> recipients, as have been noted elsewhere in this thread.
> 
> 2b. add a way to contact all PMCs about a private matter,
>  - perhaps an obvious-looking address* that contains '-private'
>  - ONLY if needed: this might be sufficiently rare as to not be needed;
> 
> (* By request, to try to reduce spam, I'm deliberately obfuscating the 
> "obvious-looking address". I'm sorry that that makes it harder to follow. See 
> start of thread for plain disclosure.)
> 
> -- 
> - Julian
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Feedback requested: New committer invitation template

[Craig Russell]

Hi,

In order to simplify the process of granting new committers write access to a 
project's repository, I'd like to propose a change in the invitation letter 
sent to candidates after the PMC has voted to accept them as committers.

The original is at 
https://community.apache.org/newcommitter.html#committer-invite-template

It does not distinguish among these three cases: already have an Apache id, 
already filed an ICLA, and have not filed an ICLA. There are many cases where 
unnecessary work is done because of improper guidance.


To: joeblo...@foo.net
Cc: private@[PROJECT].apache.org
Subject: Invitation to become [PROJECT] committer: Joe Bloggs

Hello [invitee name],

The [Project] Project Management Committee] (PMC) 
hereby offers you committer privileges to the project 
[as well as membership in the PMC]. These privileges are
offered on the understanding that you'll use them
reasonably and with common sense. We like to work on trust
rather than unnecessary constraints.

Being a committer enables you to more easily make 
changes without needing to go through the patch 
submission process. [Being a PMC member enables you 
to guide the direction of the project.]

Being a committer does not require you to 
participate any more than you already do. It does 
tend to make one even more committed.  You will 
probably find that you spend more time here.

Of course, you can decline and instead remain as a 
contributor, participating as you do now.

A. This personal invitation is a chance for you to 
accept or decline in private.  Either way, please 
let us know in reply to the [priv...@project.apache.org] 
address only.

[check http://people.apache.org/committer-index.html]
[B. If you accept, since you already have an Apache id,
the PMC will grant you write access to the repository.
]

[check http://people.apache.org/unlistedclas.html]
[B. If you accept, since you already have an iCLA on file,
the PMC will request an Apache id for you. In your response,
please choose an id that is not already in use. See
http://people.apache.org/committer-index.html
]

[B. If you accept, the next step is to register an iCLA:
1. Details of the iCLA and the forms are found 
through this link: http://www.apache.org/licenses/#clas

2. Instructions for its completion and return to 
the Secretary of the ASF are found at
http://www.apache.org/licenses/#submitting
Do not submit ICLAs to anyone but secretary, but
please do cc: [priv...@project.apache.org] 

3. When you transmit the completed iCLA, request 
to notify the Apache [Project] and choose a 
unique Apache id. Look to see if your preferred 
id is already taken at 
http://people.apache.org/committer-index.html 
This will allow the Secretary to notify the PMC 
when your iCLA has been recorded.
]

When your reply to this invitation is received, you will 
receive a follow-up message with the next steps for 
establishing you as a committer.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


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

Re: Feedback requested: New committer invitation template

[Craig Russell]

Hi Tony,

> On Dec 29, 2018, at 4:47 PM, Tony Kurc  wrote:
> 
> Craig,
> This looks great. I'm definitely +1.  I assume in terms of process, we can
> just start doing this right away, or is there some community process that
> needs to take place?

The only process is review of this proposed change. After I update the 
community page, there are references from other pages that will need to be 
changed. 

And I'd like to have each community that has their own templates start using an 
adaptation of this one.

Craig
> 
> Thanks, Tony
> 
> On Sat, Dec 29, 2018, 6:29 PM Craig Russell  
>> Hi,
>> 
>> In order to simplify the process of granting new committers write access
>> to a project's repository, I'd like to propose a change in the invitation
>> letter sent to candidates after the PMC has voted to accept them as
>> committers.
>> 
>> The original is at
>> https://community.apache.org/newcommitter.html#committer-invite-template
>> 
>> It does not distinguish among these three cases: already have an Apache
>> id, already filed an ICLA, and have not filed an ICLA. There are many cases
>> where unnecessary work is done because of improper guidance.
>> 
>> 
>> To: joeblo...@foo.net
>> Cc: private@[PROJECT].apache.org
>> Subject: Invitation to become [PROJECT] committer: Joe Bloggs
>> 
>> Hello [invitee name],
>> 
>> The [Project] Project Management Committee] (PMC)
>> hereby offers you committer privileges to the project
>> [as well as membership in the PMC]. These privileges are
>> offered on the understanding that you'll use them
>> reasonably and with common sense. We like to work on trust
>> rather than unnecessary constraints.
>> 
>> Being a committer enables you to more easily make
>> changes without needing to go through the patch
>> submission process. [Being a PMC member enables you
>> to guide the direction of the project.]
>> 
>> Being a committer does not require you to
>> participate any more than you already do. It does
>> tend to make one even more committed.  You will
>> probably find that you spend more time here.
>> 
>> Of course, you can decline and instead remain as a
>> contributor, participating as you do now.
>> 
>> A. This personal invitation is a chance for you to
>> accept or decline in private.  Either way, please
>> let us know in reply to the [priv...@project.apache.org]
>> address only.
>> 
>> [check http://people.apache.org/committer-index.html]
>> [B. If you accept, since you already have an Apache id,
>> the PMC will grant you write access to the repository.
>> ]
>> 
>> [check http://people.apache.org/unlistedclas.html]
>> [B. If you accept, since you already have an iCLA on file,
>> the PMC will request an Apache id for you. In your response,
>> please choose an id that is not already in use. See
>> http://people.apache.org/committer-index.html
>> ]
>> 
>> [B. If you accept, the next step is to register an iCLA:
>>1. Details of the iCLA and the forms are found
>>through this link: http://www.apache.org/licenses/#clas
>> 
>>2. Instructions for its completion and return to
>>the Secretary of the ASF are found at
>>http://www.apache.org/licenses/#submitting
>>Do not submit ICLAs to anyone but secretary, but
>>please do cc: [priv...@project.apache.org]
>> 
>>3. When you transmit the completed iCLA, request
>>to notify the Apache [Project] and choose a
>>unique Apache id. Look to see if your preferred
>>id is already taken at
>>http://people.apache.org/committer-index.html
>>This will allow the Secretary to notify the PMC
>>when your iCLA has been recorded.
>> ]
>> 
>> When your reply to this invitation is received, you will
>> receive a follow-up message with the next steps for
>> establishing you as a committer.
>> 
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Feedback requested: New committer invitation template

[Craig Russell]

Hi Hugo,

The intent is for the PMC member sending the invitation to do the check before 
sending the mail and edit the mail so the candidate only sees the appropriate 
option. 

I'll try to make this more clear in the instructions on the page that contains 
the sample email. [I originally had three different sample emails but they were 
all the same except for the paragraph B.]

Thanks for the feedback.

Craig

> On Dec 29, 2018, at 9:32 PM, Hugo Louro  wrote:
> 
> Hi Craig, 
> 
> +1 for the overall proposal. There is only one thing that I would like to 
> clarify. Do you plan to have a custom email for each of the three cases 
> (already have an Apache id, already filed an ICLA, and have not filed an 
> ICLA), and research ahead of time to which case the person applies, or have 
> an email that covers all the cases. If the later, my suggestion is that the 
> email should clearly direct the recipient to choose specifically the case 
> that applies to her/himself. I mean, have written something along the lines: 
> If you already have an Apache is, follow these instructions, if already filed 
> an ICLA follow these other instructions, otherwise follow this instead. 
> 
> Thanks,
> Hugo
> 
>> On Dec 29, 2018, at 3:29 PM, Craig Russell  wrote:
>> 
>> Hi,
>> 
>> In order to simplify the process of granting new committers write access to 
>> a project's repository, I'd like to propose a change in the invitation 
>> letter sent to candidates after the PMC has voted to accept them as 
>> committers.
>> 
>> The original is at 
>> https://community.apache.org/newcommitter.html#committer-invite-template
>> 
>> It does not distinguish among these three cases: already have an Apache id, 
>> already filed an ICLA, and have not filed an ICLA. There are many cases 
>> where unnecessary work is done because of improper guidance.
>> 
>> 
>> To: joeblo...@foo.net
>> Cc: private@[PROJECT].apache.org
>> Subject: Invitation to become [PROJECT] committer: Joe Bloggs
>> 
>> Hello [invitee name],
>> 
>> The [Project] Project Management Committee] (PMC) 
>> hereby offers you committer privileges to the project 
>> [as well as membership in the PMC]. These privileges are
>> offered on the understanding that you'll use them
>> reasonably and with common sense. We like to work on trust
>> rather than unnecessary constraints.
>> 
>> Being a committer enables you to more easily make 
>> changes without needing to go through the patch 
>> submission process. [Being a PMC member enables you 
>> to guide the direction of the project.]
>> 
>> Being a committer does not require you to 
>> participate any more than you already do. It does 
>> tend to make one even more committed.  You will 
>> probably find that you spend more time here.
>> 
>> Of course, you can decline and instead remain as a 
>> contributor, participating as you do now.
>> 
>> A. This personal invitation is a chance for you to 
>> accept or decline in private.  Either way, please 
>> let us know in reply to the [priv...@project.apache.org] 
>> address only.
>> 
>> [check http://people.apache.org/committer-index.html]
>> [B. If you accept, since you already have an Apache id,
>> the PMC will grant you write access to the repository.
>> ]
>> 
>> [check http://people.apache.org/unlistedclas.html]
>> [B. If you accept, since you already have an iCLA on file,
>> the PMC will request an Apache id for you. In your response,
>> please choose an id that is not already in use. See
>> http://people.apache.org/committer-index.html
>> ]
>> 
>> [B. If you accept, the next step is to register an iCLA:
>>   1. Details of the iCLA and the forms are found 
>>   through this link: http://www.apache.org/licenses/#clas
>> 
>>   2. Instructions for its completion and return to 
>>   the Secretary of the ASF are found at
>>   http://www.apache.org/licenses/#submitting
>>   Do not submit ICLAs to anyone but secretary, but
>>   please do cc: [priv...@project.apache.org] 
>> 
>>   3. When you transmit the completed iCLA, request 
>>   to notify the Apache [Project] and choose a 
>>   unique Apache id. Look to see if your preferred 
>>   id is already taken at 
>>   http://people.apache.org/committer-index.html 
>>   This will allow the Secretary to notify the PMC 
>>   when your iCLA has been recorded.
>> ]
>> 
>> When your reply to this invitation is received, you will 
>> receive a 

Re: Feedback requested: New committer invitation template

[Craig Russell]

Hi Daniel,

The work you did here is indeed excellent. The only trouble I have with it is 
that most people cannot use a mouse or trackball or touch pad to create a 
signature that looks anything like their signature. [This is the same issue I 
have with voting machines that verify voters' signatures against touch 
pad/mouse signatures.]

That said, I have no issue if you would like to update the official web page 
with instructions on how to use this tool. 
http://www.apache.org/licenses/#submitting

If you can update the tool to allow the user to sign electronically (and to 
upload their public key) it will get my enthusiastic support.

Regards,

Craig

> On Dec 30, 2018, at 10:24 AM, Daniel Gruno  wrote:
> 
> On 12/30/18 6:41 PM, Matt Sicker wrote:
>> I like this template suggestion. It may also be helpful to note that the
>> Apache ids must be letters and numbers only as some people request special
>> characters in their ids.
> 
> Not to toot my own horn too much, but we also have https://asf.icla.online/ 
> which simplifies the print-type-sign-scan-email routine for Apache ICLAs (and 
> does verify that user ID is both available and matches our syntax). Could be 
> an idea to point to that for easy ICLA work :)
> 
> 
>> On Sun, Dec 30, 2018 at 09:24, Craig Russell  wrote:
>>> Hi Hugo,
>>> 
>>> The intent is for the PMC member sending the invitation to do the check
>>> before sending the mail and edit the mail so the candidate only sees the
>>> appropriate option.
>>> 
>>> I'll try to make this more clear in the instructions on the page that
>>> contains the sample email. [I originally had three different sample emails
>>> but they were all the same except for the paragraph B.]
>>> 
>>> Thanks for the feedback.
>>> 
>>> Craig
>>> 
>>>> On Dec 29, 2018, at 9:32 PM, Hugo Louro  wrote:
>>>> 
>>>> Hi Craig,
>>>> 
>>>> +1 for the overall proposal. There is only one thing that I would like
>>> to clarify. Do you plan to have a custom email for each of the three cases
>>> (already have an Apache id, already filed an ICLA, and have not filed an
>>> ICLA), and research ahead of time to which case the person applies, or have
>>> an email that covers all the cases. If the later, my suggestion is that the
>>> email should clearly direct the recipient to choose specifically the case
>>> that applies to her/himself. I mean, have written something along the
>>> lines: If you already have an Apache is, follow these instructions, if
>>> already filed an ICLA follow these other instructions, otherwise follow
>>> this instead.
>>>> 
>>>> Thanks,
>>>> Hugo
>>>> 
>>>>> On Dec 29, 2018, at 3:29 PM, Craig Russell 
>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> In order to simplify the process of granting new committers write
>>> access to a project's repository, I'd like to propose a change in the
>>> invitation letter sent to candidates after the PMC has voted to accept them
>>> as committers.
>>>>> 
>>>>> The original is at
>>> https://community.apache.org/newcommitter.html#committer-invite-template
>>>>> 
>>>>> It does not distinguish among these three cases: already have an Apache
>>> id, already filed an ICLA, and have not filed an ICLA. There are many cases
>>> where unnecessary work is done because of improper guidance.
>>>>> 
>>>>> 
>>>>> To: joeblo...@foo.net
>>>>> Cc: private@[PROJECT].apache.org
>>>>> Subject: Invitation to become [PROJECT] committer: Joe Bloggs
>>>>> 
>>>>> Hello [invitee name],
>>>>> 
>>>>> The [Project] Project Management Committee] (PMC)
>>>>> hereby offers you committer privileges to the project
>>>>> [as well as membership in the PMC]. These privileges are
>>>>> offered on the understanding that you'll use them
>>>>> reasonably and with common sense. We like to work on trust
>>>>> rather than unnecessary constraints.
>>>>> 
>>>>> Being a committer enables you to more easily make
>>>>> changes without needing to go through the patch
>>>>> submission process. [Being a PMC member enables you
>>>>> to guide the direction of the project.]
>>>>> 
>>>>

Re: Feedback requested: New committer invitation template

[Craig Russell]

Hi Joan,



> On Dec 30, 2018, at 11:22 AM, Joan Touzet  wrote:
> 
> Nice work, Daniel - that should definitely be incorporated. It's a big
> improvement over a template that a human has to review before 

Thanks for this feedback.
> 
> In addition to this, we over at CouchDB found the intro text a bit too
> forceful for our tastes - too much guilt tripping and expectation
> setting. It's also in our opinion premature to start talking about ICLAs
> until the candidate actually accepts.
> 
> Here's how we adapted this email to be friendlier (including links to our
> project bylaws and CoC):
> 
> 8<8<8<8<8<8<8<8<8<8<
> 
> Dear %NAME%,
> 
> The Apache CouchDB Project Management Committee (PMC) would like to invite 
> you to become a committer. Committers are given a binding vote in certain 
> project decisions, as well as write access to public project infrastructure.
> 
> We value your contributions to date, and believe that you are committed to 
> the project. We mean this in the sense of being loyal to the project and its 
> interests. It is a position of trust, not an expectation of activity level.
> 
> You can read more about the role in our bylaws:
> 
>http://couchdb.apache.org/bylaws.html#committers
> 
> Please also familiarise yourself with our code of conduct:
> 
>http://couchdb.apache.org/conduct.html
> 
> While these documents apply to all community members, by accepting this 
> invitation you are indicating that you have read and agree to them.
> 
> Accepting this invitation does not obligate you to contribute. The ASF is a 
> volunteer organisation and it is normal for people's contribution levels to 
> vary. We welcome more contributions from you, but there is no expectation, 
> and this position of trust will not expire through inactivity.
> 
> Of course, you can decline and continue to contribute as you do now. If you 
> do decline, it will be kept private, unless you say otherwise.
> 
> Either way, please let us know in reply to the priv...@couchdb.apache.org 
> list only. If you accept, we will announce your new position on the 
> d...@couchdb.apache.org list after your account is created.

I appreciate that your process is different from the community guidelines, and 
that your community prefers to have the candidate reply before sending further 
instructions (which as you point out might assume that by default the candidate 
intends to accept). 

But this change would be a step too far for me to endorse without significant 
additional discussions. One reason that the process is as it is now is to 
streamline the process of granting commit rights to new community members, and 
your process would tend to delay it.
> 
> On behalf of the CouchDB PMC,
> %YOURNAME%
> 8<8<8<8<8<8<8<8<8<8<
> 
> Once this is accepted by the candidate, we then send through instructions to 
> sign an ICLA, which I'm now updating to use Humbedooh's lovely online 
> generator.

I'm hoping that you will use this opportunity to send one of the three revised 
section B paragraphs to avoid unnecessary delay in granting commit rights to 
the candidate.

Regards,

Craig
> 
> You can see all of our PMC form letters here:
> 
> https://github.com/apache/couchdb-admin/tree/master/email
> 
> -Joan
> 
> - Original Message -
>> From: "Daniel Gruno" 
>> To: dev@community.apache.org, gene...@incubator.apache.org
>> Sent: Sunday, December 30, 2018 1:24:20 PM
>> Subject: Re: Feedback requested: New committer invitation template
>> 
>> On 12/30/18 6:41 PM, Matt Sicker wrote:
>>> I like this template suggestion. It may also be helpful to note
>>> that the
>>> Apache ids must be letters and numbers only as some people request
>>> special
>>> characters in their ids.
>> 
>> Not to toot my own horn too much, but we also have
>> https://asf.icla.online/ which simplifies the
>> print-type-sign-scan-email
>> routine for Apache ICLAs (and does verify that user ID is both
>> available
>> and matches our syntax). Could be an idea to point to that for easy
>> ICLA
>> work :)
>> 
>> 
>>> 
>>> On Sun, Dec 30, 2018 at 09:24, Craig Russell 
>>> wrote:
>>> 
>>>> Hi Hugo,
>>>> 
>>>> The intent is for the PMC member sending the invitation to do the
>>>> check
>>>> before sending the mail and edit the mail so the candidate only
>>>> sees the
>>>> appropriate option.
>>>> 
>>>>

Re: Beam's recent community development work

[Craig Russell]

Hi Kenn,

Thanks for contributing this. I think it's a nice introduction to Beam's 
community building efforts.

Here are a couple of comments:

We want our contributor-base (hence committer-base) to be more spread across 
companies and backgrounds, for the usual Apache reasons.

I'd elaborate instead of saying "for the usual Apache reasons". Which reasons 
are important to Beam?

(we have committers from community development, tech writing, training, etc).

I'd make this a sentence of its own.

you shouldn't be proposing a committer for other reasons, 

I don't understand "for other reasons".

Every ~month, we call for new discussions and revisit ~all prior discussions. 

I find the "~" to be distracting. Words please.

For a potential committer, we did this:

It's not clear to me when a person becomes a potential committer. Is it in the 
"repeat contributor" phase?

For an early contributor, 

Perhaps move this paragraph above the "For a potential committer" paragraph?

~3~4 obvious committer candidates

As above, remove "~".

If we have no feedback about which guidelines were a concern, that is a red 
flag that we are being driven by bias.

I don't understand this. Lack of concern might be considered a "good thing" not 
a red flag.

as RMS says 

Who/what is RMS?

Regards,

Craig
> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles  wrote:
> 
> Here it is:
> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
> 
> Kenn
> 
> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas 
> wrote:
> 
>> Where could we find it?
>> 
>> 
>> 
>> 
>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles  wrote:
>> 
>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>> bdelacre...@apache.org>
>>> wrote:
>>> 
 Feel free to draft your blog post and we can then review and publish!
 
>>> 
>>> I've drafted it. It is pretty long but still feels terse to me. Feedback
>>> very welcome on that point. I will try to find time to give it another
>>> pass, unless someone tells me that it is fine as-is.
>>> 
>>> Kenn
>>> 
>>> 
>>> -Bertrand
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
 For additional commands, e-mail: dev-h...@community.apache.org
 
 
>>> 
>> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Beam's recent community development work

[Craig Russell]

I realize that this message might be hard to read since copy/paste formatting 
is gone. So here goes my attempt to clarify...

On Jan 7, 2019, at 8:28 AM, Craig Russell  wrote:

Hi Kenn,

Thanks for contributing this. I think it's a nice introduction to Beam's 
community building efforts.

Here are a couple of comments:

> We want our contributor-base (hence committer-base) to be more spread across 
> companies and backgrounds, for the usual Apache reasons.

I'd elaborate instead of saying "for the usual Apache reasons". Which reasons 
are important to Beam?

> (we have committers from community development, tech writing, training, etc).


I'd make this a sentence of its own.

> you shouldn't be proposing a committer for other reasons, 

I don't understand "for other reasons".

> Every ~month, we call for new discussions and revisit ~all prior discussions. 

I find the "~" to be distracting. Words please.

> For a potential committer, we did this:

It's not clear to me when a person becomes a potential committer. Is it in the 
"repeat contributor" phase?

> For an early contributor, 

Perhaps move this paragraph above the "For a potential committer" paragraph?

> ~3~4 obvious committer candidates


As above, remove "~".

> If we have no feedback about which guidelines were a concern, that is a red 
> flag that we are being driven by bias.


I don't understand this. Lack of concern might be considered a "good thing" not 
a red flag.

> as RMS says 

Who/what is RMS?

Regards,

Craig
>> On Jan 4, 2019, at 1:49 PM, Kenneth Knowles > <mailto:k...@apache.org>> wrote:
>> 
>> Here it is:
>> https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building
>>  
>> <https://blogs.apache.org/roller-ui/authoring/preview/comdev/?previewEntry=an-approach-to-community-building>
>> 
>> Kenn
>> 
>> On Fri, Jan 4, 2019 at 1:44 PM Griselda Cuevas 
>> wrote:
>> 
>>> Where could we find it?
>>> 
>>> 
>>> 
>>> 
>>> On Fri, 4 Jan 2019 at 13:35, Kenneth Knowles  wrote:
>>> 
>>>> On Wed, Oct 31, 2018 at 8:51 AM Bertrand Delacretaz <
>>>> bdelacre...@apache.org>
>>>> wrote:
>>>> 
>>>>> Feel free to draft your blog post and we can then review and publish!
>>>>> 
>>>> 
>>>> I've drafted it. It is pretty long but still feels terse to me. Feedback
>>>> very welcome on that point. I will try to find time to give it another
>>>> pass, unless someone tells me that it is fine as-is.
>>>> 
>>>> Kenn
>>>> 
>>>> 
>>>> -Bertrand
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>>>> For additional commands, e-mail: dev-h...@community.apache.org
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
> <http://db.apache.org/jdo>

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Proposed process for recognizing *Non-Technical* Contributions

[Craig Russell]

Hi Sally,

> On Jan 10, 2019, at 12:53 AM, Sally Khudairi  wrote:
> 
Great writeup and I can wholeheartedly agree with everything except this:

> 3) All project/committee participants are encouraged to sign an ASF ICLA in 
> order to have their contributions recognized.

With my Secretary hat on: It is really a lot of work to process non-CLA 
contributors. So I'd change this to:

3) All project/committee participants are required to sign an ASF ICLA in order 
to have their contributions recognized.

Normally this will have been done in step 2 but your writeup seems to imply 
that filing an ICLA is optional. My recommendation: not optional.

Regards,

Craig

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Proposed process for recognizing *Non-Technical* Contributions

[Craig Russell]

Hi Sharan,

> On Jan 13, 2019, at 5:59 AM, Sharan Foga  wrote:
> 
> Hi Craig
> 
> One thing that we have done in OFBiz is that when a contributor requests 
> access to our wiki, we ask them to complete an ICLA before the access request 
> is processed. This has helped to capture people who for example want to 
> create documentation.

This is a terrific idea. I think we should add something to the PMC pages about 
recognizing contributions and asking contributors to file ICLAs.

In addition to the community building and the recognition, filing an ICLA has 
subsequent benefits to the project and the future committer. Just as soon as 
the PMC decides to invite the contributor to become a committer, they can 
finish the process without any delays.

I'll propose some updates to the PMC community pages to reflect this.

Craig
> 
> We have setup a page with some basic explanations of what an ICLA is and why 
> we are asking them to sign one.
> 
> https://s.apache.org/NrGP <https://s.apache.org/NrGP>
> 
> As well as setting them up with wiki access, we flag them in our Jira as part 
> of a contributor group where they can then actually start assigning tasks 
> (including the non technical ones) to themselves. 
> 
> Perhaps this could be one of the potential suggestions that we could include 
> for projects.
> 
> Thanks
> Sharan
> 
> On 2019/01/10 15:52:19, Craig Russell  <mailto:apache@gmail.com>> wrote: 
>> Hi Sally,
>> 
>>> On Jan 10, 2019, at 12:53 AM, Sally Khudairi  wrote:
>>> 
>> Great writeup and I can wholeheartedly agree with everything except this:
>> 
>>> 3) All project/committee participants are encouraged to sign an ASF ICLA in 
>>> order to have their contributions recognized.
>> 
>> With my Secretary hat on: It is really a lot of work to process non-CLA 
>> contributors. So I'd change this to:
>> 
>> 3) All project/committee participants are required to sign an ASF ICLA in 
>> order to have their contributions recognized.
>> 
>> Normally this will have been done in step 2 but your writeup seems to imply 
>> that filing an ICLA is optional. My recommendation: not optional.
>> 
>> Regards,
>> 
>> Craig
>> 
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org <mailto:c...@apache.org> <mailto:c...@apache.org 
>> <mailto:c...@apache.org>> http://db.apache.org/jdo 
>> <http://db.apache.org/jdo> <http://db.apache.org/jdo 
>> <http://db.apache.org/jdo>>
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 
> <mailto:dev-unsubscr...@community.apache.org>
> For additional commands, e-mail: dev-h...@community.apache.org 
> <mailto:dev-h...@community.apache.org>
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Proposed process for recognizing *Non-Technical* Contributions

[Craig Russell]

> On Jan 20, 2019, at 9:52 PM, Craig Russell  wrote:
> 
> Hi Sharan,
> 
>> On Jan 13, 2019, at 5:59 AM, Sharan Foga > <mailto:sha...@apache.org>> wrote:
>> 
>> Hi Craig
>> 
>> One thing that we have done in OFBiz is that when a contributor requests 
>> access to our wiki, we ask them to complete an ICLA before the access 
>> request is processed. This has helped to capture people who for example want 
>> to create documentation.
> 
> This is a terrific idea. I think we should add something to the PMC pages 
> about recognizing contributions and asking contributors to file ICLAs.

Thinking about this some more, we might even recommend that the PMC actively 
monitor contributions from non-committers, not just those who request access to 
the wiki; and suggest that they should submit an ICLA.

Craig
> 
> In addition to the community building and the recognition, filing an ICLA has 
> subsequent benefits to the project and the future committer. Just as soon as 
> the PMC decides to invite the contributor to become a committer, they can 
> finish the process without any delays.
> 
> I'll propose some updates to the PMC community pages to reflect this.
> 
> Craig
>> 
>> We have setup a page with some basic explanations of what an ICLA is and why 
>> we are asking them to sign one.
>> 
>> https://s.apache.org/NrGP <https://s.apache.org/NrGP>
>> 
>> As well as setting them up with wiki access, we flag them in our Jira as 
>> part of a contributor group where they can then actually start assigning 
>> tasks (including the non technical ones) to themselves. 
>> 
>> Perhaps this could be one of the potential suggestions that we could include 
>> for projects.
>> 
>> Thanks
>> Sharan
>> 
>> On 2019/01/10 15:52:19, Craig Russell > <mailto:apache@gmail.com>> wrote: 
>>> Hi Sally,
>>> 
>>>> On Jan 10, 2019, at 12:53 AM, Sally Khudairi >>> <mailto:s...@apache.org>> wrote:
>>>> 
>>> Great writeup and I can wholeheartedly agree with everything except this:
>>> 
>>>> 3) All project/committee participants are encouraged to sign an ASF ICLA 
>>>> in order to have their contributions recognized.
>>> 
>>> With my Secretary hat on: It is really a lot of work to process non-CLA 
>>> contributors. So I'd change this to:
>>> 
>>> 3) All project/committee participants are required to sign an ASF ICLA in 
>>> order to have their contributions recognized.
>>> 
>>> Normally this will have been done in step 2 but your writeup seems to imply 
>>> that filing an ICLA is optional. My recommendation: not optional.
>>> 
>>> Regards,
>>> 
>>> Craig
>>> 
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> c...@apache.org <mailto:c...@apache.org> <mailto:c...@apache.org 
>>> <mailto:c...@apache.org>> http://db.apache.org/jdo 
>>> <http://db.apache.org/jdo> <http://db.apache.org/jdo 
>>> <http://db.apache.org/jdo>>
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 
>> <mailto:dev-unsubscr...@community.apache.org>
>> For additional commands, e-mail: dev-h...@community.apache.org 
>> <mailto:dev-h...@community.apache.org>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
> <http://db.apache.org/jdo>
Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org <mailto:c...@apache.org> http://db.apache.org/jdo 
<http://db.apache.org/jdo>

Re: Proposed process for recognizing *Non-Technical* Contributions

[Craig Russell]

Hi Mark,

> On Jan 21, 2019, at 10:50 AM, Mark Thomas  wrote:
> 
> On 21/01/2019 17:59, Roy Lenferink wrote:
>> I think it is an excellent idea to suggest submitting an ICLA to
>> contributors when they submit a contribution.
> 
> Generally, adding barriers to participation reduces contributions rather
> than increases them.

I agree. Requiring ICLAs should be done only when the size of the contribution 
warrants it.

> 
> If folks want to submit an CLA then of course they can (and there is no
> harm in pointing this out to a new contributor) but it should remain
> optional until someone is made a committer.

Well, the criteria we have used in the past is not "someone is made a 
committer" but "the size of the contribution would make it difficult to unwind".
> 
> I'll go further and say that I have seen some projects require CLAs from
> contributors for some/all contributions and I think that is adding
> unnecessary barriers to participation.

I agree with this. Casual contributions should not require ICLAs.

But I think that we can use a request for an ICLA not as a barrier to 
contributions but an incentive to more involvement.

"We have noticed your contributions to Apache Foo and value your involvement in 
the project. We would like to invite you to submit an ICLA to cover your 
contributions. This is not required, but demonstrates your commitment to Apache 
Foo." Wordsmithing may be needed here.
> 
>> CNCF is using a bot on their GitHub repositories which adds a label to
>> every pull request whether the contributor has a cla on file [1][2].
>> More info on this here [3]
>> The cla label is checked before the PR can be merged.
>> 
>> As we're moving to a broader GitHub integration maybe it is an idea to use
>> a technology like this as well.
> 
> That would make CLAs mandatory and I disagree very strongly with any
> move in that direction.
> 
>> I can foresee a small problem with this, as AFAIK all CLAs are still
>> processed manually, but correct me if I'm wrong.
> 
> CLA processing is largely automated and work is in hand to make it more so.

Well, not so much yet. There is tooling but there is also substantial human 
involvement in the process, which IMHO is essential to preserve the integrity 
of our records.

Craig
> 
> Mark
> 
>> 
>> What do you think?
>> 
>> [1] http://home.apache.org/~rlenferink/img/cncf-cla-message.png 
>> 
>> [2] http://home.apache.org/~rlenferink/img/cncf-cla-reporting.png 
>>  (last
>> job: cla/linuxfoundation)
>> [3]
>> https://github.com/kubernetes/community/blob/master/CLA.md#the-contributor-license-agreement
>>  
>> 
>> 
>> - Roy
>> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Omission in vote summary email template

[Craig Russell]

Hi Sebb,

This page needs more than a little bit of work. I've been looking at both the 
community.apache.org pages and the apache.org/dev pages and they are not 
synchronized well and have missing information.

I'm particularly keen to fix the processes for discussing, voting, inviting, 
and accepting new committers and PMC members. There is a different process for 
these depending on the status of the candidate: no ICLA on file, ICLA on file, 
committer on this project, committer on a different project.

In order to actually fix these pages, we will need consensus on the changes and 
also the process to actually make the changes.

Craig

> On Feb 28, 2019, at 2:54 AM, sebb  wrote:
> 
> On Thu, 28 Feb 2019 at 09:52, sebb  wrote:
>> 
>> The section:
>> 
>> https://community.apache.org/newcommitter.html#close-vote
>> 
>> says to summarise the binding vote counts only.
>> 
>> I think that is wrong on two counts:
>> - non-binding votes should not be ignored
>> - individual votes should be listed to make it easy to check if all
>> votes have been included and to check binding status
> 
> Ignore the parts about binding status, as such votes are held on the
> private list and so are automatically binding (if that even makes
> sense for committer votes).
> 
> But I still think it would be useful to list the votes along with the summary.
> 
>> Can we get this changed?
>> 
>> Sebb.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: Omission in vote summary email template

[Craig Russell]

Hi Sebb,

> On Feb 28, 2019, at 2:54 AM, sebb  wrote:
> 
> On Thu, 28 Feb 2019 at 09:52, sebb  wrote:
>> 
>> The section:
>> 
>> https://community.apache.org/newcommitter.html#close-vote
>> 
>> says to summarise the binding vote counts only.
>> 
>> I think that is wrong on two counts:
>> - non-binding votes should not be ignored
>> - individual votes should be listed to make it easy to check if all
>> votes have been included and to check binding status
> 
> Ignore the parts about binding status, as such votes are held on the
> private list and so are automatically binding (if that even makes
> sense for committer votes).

The way the page is worded, I agree that "Binding" should not be part of the 
email summary.

If this is changed via CMS, is there an automatic rebuild of the web site?

Craig
> 
> But I still think it would be useful to list the votes along with the summary.
> 
>> Can we get this changed?
>> 
>> Sebb.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: on "meritocracy"

[Craig Russell]

To me, meritocracy was always a force-fit to describe what we strive for.

The terms with -ocracy all have the intended effect of invoking a top-down rule 
system of governance. I reject all such descriptions of how Apache works.

How about just "merit-based" as a guiding principle. We don't have -ocracy at 
all. We strive for merit-based governance.

Craig

> On Mar 22, 2019, at 4:47 PM, Kevin A. McGrail  wrote:
> 
> On 3/22/2019 7:28 PM, Roman Shaposhnik wrote:
>> On Fri, Mar 22, 2019 at 4:25 PM Naomi Slater  wrote:
>>> I suspect the answer is not to replace the word but to do away with it
>>> entirely
>> I still would like to have a succinct handle to reference the ethos of ASF.
> 
> 
> From my experience, there are words that are landmines in open source: 
> free and meritocracy happen to be such words without question. 
> 
> Switching meritocracy to do-ocracy might be a good way to handle it and
> I know that's what other orgs like LF have done.  However, we are
> straddling the middle of having both principles of duopolies like JFDI
> and elections with the necessary hierarchy for fiscal / corporate
> oversight.  That means the definition of do-ocracy doesn't fit.  I
> usually do mention the issues like a meritocracy often morphs into a
> dictatorship and that people can amass too much merit that it's viewed
> as harmful.  I see that when I mention my $0.02 sometimes and it's taken
> with more weight than I intend.
> 
> So like Roman, I've been search for a word or a succinct handle to refer
> to it.  I don't have an answer but agree that do-ocracy and meritocracy
> don't work well.
> 
> I usually say all the things we aren't in my Yet Another The Apache Way
> talk (TATAW per Daniel Ruggeri).  I think I'll start saying we aren't a
> meritocracy OR a do-ocracy/duopoly either but it's the closest thing I
> know of. 
> 
> I don't like the idea of NOT saying what we are so do you have
> suggestion of what word you think fits?
> 
> 
> Regards,
> KAM
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org  http://db.apache.org/jdo 

Re: on "meritocracy"

[Craig Russell]

Hi Griselda,

I was thinking along similar lines: measuring where we are, setting goals, 
making policy, putting together a team to make it happen. 

I love your enthusiasm and hope we can actually create something great from 
your ideas. Just as we recognized the value in a fund-raising group, it's time 
we had a diversity-raising group.

I agree with Sam that one of the first things to do is to establish a 
communication channel for interested parties to focus on the issue. I don't 
think we need anything more than a request to infra to make that happen.

I do think that D&I is important enough, and separate enough, from Comdev that 
a new structure is needed. I'd say that one of the first tasks for the group 
will be to recommend what that structure looks like from an organization 
standpoint. Sam has outlined some options that need to be explored.

Craig

> On Mar 29, 2019, at 9:28 AM,Griselda Cuevas  wrote:
> 
> Yes! This is exciting. I'd like to be part of the mailing list, and I agree
> that when there's a product encoded in the efforts. the cadence become
> stronger.
> 
> Here's my proposed list of deliverables by work stream:
> 
> *Diagnostic*
> 1) Revamp the 2016 contributor survey
> 2) Launch 2019 Survey (I can do this)
> 3) Analyze results and identify actionable next steps (based in pain
> points, strengths, opportunity areas, etc.)
> 4) Share results & recommendations w/ community
> 
> *Working towards improvement*
> *I can own this work stream and I need more volunteers, I commit to give
> monthly reports. D&I in OSS is part of my day-to-day job, so that's a
> guarantee I'll deliver on it. I also love the topic so I can also dedicate
> personal time to this effort. *
> 1) Curate a list of experts in D&I
> 2) Evaluate possible vendors and select the best fit
> 3) Outline statement of work (define project req.)
> 4) Hire vendor (Due diligence by the ASF)
> 5) Kick-off consulting work, focused on findings from survey.
> 
> *Embedding D&I at the ASF*
> *I want to be part of this. *
> 1) Define purpose, values and objectives for a D&I council
> 2) Define what structure makes more sense
> 3) Work on formalizing the council
> 4) Make the survey the measurement for council's impact YoY
> 
> If you like it, I'm happy to create a Jira board to track efforts.
> 
> 
> On Fri, 29 Mar 2019 at 09:08, Sam Ruby  wrote:
> 
>> On Fri, Mar 29, 2019 at 11:37 AM Griselda Cuevas
>>  wrote:
>>> 
>>> Another thing we should consider is creating a D&I council, PMC, working
>>> group (or something alike) for the ASF, and I'd love to be part of it.
>>> 
>>> Now, I have to share my feelings with discussions on this list.
>> Sometimes I
>>> struggle to understand when a conversation is ready for action. I feel
>> like
>>> I've seen so many great ideas, and I don't have visibility into when they
>>> start to happen or when I should start working on things. This time I'm
>>> offering to lead... so how could I do it?
>> 
>> TL;DR: identify a list of tangible deliverables, and I'll help you
>> make it happen.
>> 
>> Longer answer:
>> 
>> Organizationally, this could be one of the things that is done under
>> the comdev umbrella, it could be something that reports to the
>> president, or it could be something that reports to the board.
>> 
>> The third option requires a board resolution.  The middle option is
>> less clear, but in such cases we err on the side of clarity so a board
>> resolution would be prepared.  No board interaction is required for
>> the first option, though a notification in the next board report would
>> be in order.
>> 
>> Operationally, this would start pretty much the way everything starts
>> at the ASF: with the creation of a mailing list.  What this will be is
>> a quieter place where people who actually want to do the work get
>> together and make it happen.  I will caution you that often times,
>> those people don't show up, and this ultimately means that it becomes
>> a place to ideas go to die.  And I will say that similar efforts have
>> died this way in the past.
>> 
>> Part of what makes PMCs work is that they have a tangle product (code)
>> and deliverables (releases).  This helps keep things focused.
>> 
>> Outside of the Code of Conduct, focus is not a word I would use to
>> characterize most of the discussions to date on diversity.  We need to
>> fix that.
>> 
>> So... if we (and by that I'm specifically looking for volunteers) can
>> identify tangible work products and there is a commitment to provide
>> written monthly status reports detailing progress towards the
>> production of those work products, I am prepared to support the
>> creation of an officer and committee responsible.  I don't believe
>> that this committee needs board authority (at least not yet), and Ross
>> and I both clearly are interested in making this work.  This leads me
>> to recommend a path of the creation of a President's committee.
>> 
>> Circling back, board resolutions are generally evaluated monthly (out
>

Re: on "meritocracy"

[Craig Russell]

Before we get locked into this JIRA, could we consider changing its name to 
DIVERSITY instead of DI ?

Craig

> On Apr 2, 2019, at 10:06 AM, Griselda Cuevas  wrote:
> 
> @joan - I also get a Pony, I requested the Jira ;)
> 
> On Tue, Apr 2, 2019, 10:03 AM Joan Touzet  wrote:
> 
>> 
>> 
>> 
>> Daniel wrote:
>> 
>>> Requested, and should be ready within an hour or two.
>> 
>> Thank you! You get a pony!
>> 
>> -Joan "JFDI" Touzet
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 

Craig Russell
Member, Apache Incubator PMC
apache@gmail.com

Please review/merge this PR

[Craig Russell]

This PR is ready for comments in preparation for merge to main.

Regards,
Craig

> Begin forwarded message:
> 
> From: clr-apache (via GitHub) 
> Subject: [GitHub] [comdev-site] clr-apache commented on pull request #82: 
> Update newcommitter.md
> Date: February 3, 2023 at 14:59:53 PST
> To: dev@community.apache.org 
> Reply-To: dev@community.apache.org
> 
> 
> clr-apache commented on PR #82:
> URL: https://github.com/apache/comdev-site/pull/82#issuecomment-1416505062
> 
>   This PR updates the recommended process for inviting new committers/PMC 
> members. It has detailed instructions to the candidate in cases where they 
> already have an Apache id or have previously filed an ICLA.
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org

Re: Idea: build a New Contributor Guide Tool

[Craig Russell]

As an experiment, I logged into chat.openai.com and asked it to tell me how to 
contribute code to Apache. [1] Then I asked why the ICLA is needed. [2]

These AI are smarter than we might think,

I expect that refining the questions and editing the replies might be easier 
than creating the content by hand.

WDYAT?

Craig

[1]I asked:

how do i contribute code to The Apache Software Foundation?

They replied:

To contribute code to the Apache Software Foundation (ASF), you need to follow 
these steps:

Choose a project: Browse the list of Apache projects and find one that aligns 
with your area of expertise.

Get involved: Participate in the project's community by asking questions, 
contributing documentation, and providing feedback.

Set up your development environment: Follow the project's guidelines for 
setting up your development environment.

Sign and submit an ICLA: The Apache Software Foundation requires contributors 
to sign a Contributor License Agreement (CLA). This document outlines your 
rights and obligations as a contributor to the ASF.

Create a patch or feature branch: Develop your changes in a separate branch and 
submit a patch or feature request to the project's mailing list or issue 
tracker.

Follow the project's coding standards: Ensure that your code follows the 
project's coding standards and style guide.

Engage in code review: Be prepared to engage in a code review process with 
other project contributors.

Merge your changes: Once your changes have been reviewed and approved, they 
will be merged into the project's main codebase.

Note: The specifics of the contribution process may vary from project to 
project, so be sure to consult the project's guidelines for more information.

[2] why is an ICLA needed for Apache?

The Apache Software Foundation requires contributors to sign a Contributor 
License Agreement (CLA) in order to ensure that the code contributed to its 
projects can be distributed under the terms of the Apache License. The Apache 
License is a permissive open-source license that allows for the use, 
modification, and distribution of software, but requires that the original 
copyright notices and license terms are preserved.

The ICLA is a legal agreement between the contributor and the ASF that 
clarifies the rights and responsibilities of both parties. By signing the ICLA, 
the contributor grants the ASF a perpetual, non-exclusive, no-charge, worldwide 
license to use, copy, modify, distribute, and sublicense the contribution, and 
agrees to hold the ASF harmless from any claims related to the contribution.

The ICLA helps the ASF to maintain a clear chain of custody for the code in its 
projects, and protects the integrity of the Apache brand by ensuring that all 
contributions are made in accordance with the ASF's legal and ethical standards.
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

The Lone Developer Problem

[Craig Russell]

I thought this might be of general interest. Enjoy!

https://evanhahn.com/the-lone-developer-problem/?utm_source=clr

Craig L Russell
c...@apache.org


-
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

[Craig Russell]

> On Mar 16, 2023, at 10:07, sebb  wrote:
> 
> I think there need to be 3 mailing lists instead of just dev@
> 
> general community help
> GSOC
> tool development
> 
> I agree having a separate JIRA for GSOC would be a good idea.
> That would leave COMDEV for the website and various tools.

This is an excellent idea. GSOC is a great sub-project and has lots of interest 
and deserves its own space.

Craig
> 
> Sebb
> 
> On Thu, 16 Mar 2023 at 16:31, Maxim Solodovnik  wrote:
>> 
>> On Thu, 16 Mar 2023 at 23:29, Daniel Gruno  wrote:
>>> 
>>> On 3/16/23 11:26, Maxim Solodovnik wrote:
 
 almost all communications are already at mentors@community :)
 
>>> 
>>> And yet we have 185 messages on this list in just the past month. I do
>>> believe splitting GSOC out from the COMDEV Jira space will make most of
>>> that go away.
>> 
>> Separate GSoC project in JIRA is a great idea!
>> Thanks for it :)))
>> 
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
>> 
>> 
>> --
>> Best regards,
>> Maxim
>> 
>> -
>> 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
> 

Craig L Russell
c...@apache.org


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

Re: Standardise on 'main' as the default branch?

[Craig Russell]

Yes, of course change master to main.

Craig

> On Apr 2, 2023, at 04:33, sebb  wrote:
> 
> On Sun, 2 Apr 2023 at 09:39, Christofer Dutz  
> wrote:
>> 
>> I would like to make a slightly different proposal.
>> Name the branch, on which development happens "develop" and the one that 
>> contains the released versions "releases". With "main" you never really know 
>> what it's used for.
> 
> I agree that main is no less ambiguous than master, but the website
> does not really have a development/release cycle, so I'm not sure
> 'release' is appropriate here.
> 
> Maybe the default branch should be something like 'production' or
> 'live' for websites.
> However that would mean changing the other repos to keep in step.
> 
>> But I think I brought this up multiple times before, so if be +1 on a change.
> 
> Thanks!
> 
>> Chris
>> 
>> Gesendet von Outlook für Android
>> 
>> From: Willem Jiang 
>> Sent: Sunday, April 2, 2023 10:19:44 AM
>> To: dev@community.apache.org 
>> Subject: Re: Standardise on 'main' as the default branch?
>> 
>> +1 for it.
>> 
>> Willem Jiang
>> 
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>> 
>> On Sat, Apr 1, 2023 at 8:11 PM sebb  wrote:
>>> 
>>> All bar one of the 4 comdev Git repos use 'main' as the default branch.
>>> 
>>> I think we should standardise on that going forward, and change the
>>> default branch for comdev-site.
>>> 
>>> Agreed?
>>> 
>>> Sebb
>>> 
>>> -
>>> 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
> 

Craig L Russell
c...@apache.org


-
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

[Craig Russell]

I would put a link to the tags page in lots of places, including the top of the 
apache.org main page, just after 
> Projects 
>  
> People 
>  
> Community 
>  
> Infrastructure 
>  
> License 
>  
> Sponsors 
>  
And maybe on the main comdev page https://community.apache.org/about/ just after
faq 
navigation 

Craig

> On Apr 27, 2023, at 09:51, rbo...@rcbowen.com wrote:
> 
> 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 
> 
Craig L Russell
c...@apache.org

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

[Craig Russell]

I agree there is too much overlap among the four pages, and would lean toward 
one page with decision making as the primary driver. Contents of the other 
pages could fit well into that page..

Craig

> On May 30, 2023, at 12:45, rbo...@rcbowen.com wrote:
> 
> 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
> 

Craig L Russell
c...@apache.org


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

Re: [PR] What makes a good report? (comdev-site)

[Craig Russell]

> On Jun 23, 2023, at 16:28, Rich Bowen  wrote:
> 
> On Fri, Jun 23, 2023, 06:10 rlenferink (via GitHub)  wrote:
> 
>> 
>> rlenferink commented on code in PR #125:
>> URL: https://github.com/apache/comdev-site/pull/125#discussion_r1239637617
>> 
>> 
>> 
>> Review Comment:
>>   Great addition! Should we maybe link to
>> https://whimsy.apache.org/board/minutes/ if people want to easily select
>> another project and have a look at their past reports ?
>> 
> 
> That's private but yeah I will link to the public version of that.

The board agenda is private, including director comments and sections of 
reports marked with  flags. 

The secretary creates a subset of the agenda which becomes the minutes, which 
after approval by the board are published to the public.

Craig

> 
>> 

Craig L Russell
c...@apache.org


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

Re: [PR] What makes a good report? (comdev-site)

[Craig Russell]

> On Jun 26, 2023, at 05:29, Rich Bowen  wrote:
> 
> In the past we have avoided linking to whimsy in public facing
> documentation. It encourages people to dig to find what they can find.
> Whimsy is *not* a place that we want people digging, IMHO, and if there's
> alternate (there is) we should use it.

I completely agree. The board minutes are published here:
https://apache.org/foundation/board/calendar.html

> 
> On Fri, Jun 23, 2023, 19:47 sebb  wrote:
> 
>> On Sat, 24 Jun 2023 at 00:28, Rich Bowen  wrote:
>>> 
>>> On Fri, Jun 23, 2023, 06:10 rlenferink (via GitHub) 
>> wrote:
>>> 
 
 rlenferink commented on code in PR #125:
 URL:
>> https://github.com/apache/comdev-site/pull/125#discussion_r1239637617
 
 
 
 Review Comment:
   Great addition! Should we maybe link to
 https://whimsy.apache.org/board/minutes/ if people want to easily
>> select
 another project and have a look at their past reports ?
 
>>> 
>>> That's private but yeah I will link to the public version of that.
>> 
>> $ curl -I https://whimsy.apache.org/board/minutes/
>> HTTP/1.1 200 OK
>> 
>> Looks public to me ...
>> 
 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 

Craig L Russell
c...@apache.org


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

Re: Improving Onboarding Experiences - Updating PMC Chair onboarding

[Craig Russell]

Hi Shane,

Thanks for taking on this task. A couple of comments:

1. Congratulations on being appointed by the board as a project VP and Chair of 
your PMC!

I do not believe that there is a "project VP". There is an ASF VP and a project 
Chair. So I'd change this to :

Congratulations on being appointed by the board as an ASF VP and Chair of your 
project's PMC!

The same text appears in 1) and 2)

2. I believe that since the adoption of these standards, the board created the 
concept of a Roll Call. While not needed for the welcome-to-new-pmc-chairs, the 
material linked should be updated to include the concept. 

3. In the reporting description of new committers and PMC members:
When were the newest committers or PMC members elected? [REQUIRED]

The report should specially not name prospective committers or PMC members that 
are currently being voted or invited but have not accepted. Only committers or 
PMC members that have been added to the roster should be mentioned. Any 
in-process candidates should be included in the next report.

Regards,
Craig

> On Jul 30, 2023, at 11:34, Shane Curcuru  wrote:
> 
> I plan to update the email and how-to information we provide to new PMC 
> members.  Please comment or make any factual corrections on the wiki:
> 
> https://cwiki.apache.org/confluence/display/COMDEV/PMC+Chair+Onboarding+Change+Proposal
> 
> I'll be working with M&P to see where this fits on the a.o/dev tree.
> 
> -- 
> - Shane
>  ComDev PMC
>  The Apache Software Foundation
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

[Craig Russell]

Hi Christofer,

As long as projects with their own settings can continue to use them, I'm

+1

to change the defaults for all projects. If the projects don't like being able 
to use their lists again, they can always go back to what they had before.

Thanks,
Craig

> On Aug 1, 2023, at 05: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
> 
> 

Craig L Russell
c...@apache.org


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

[Craig Russell]

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.

Craig

> - change the default
> 
> Mark
> 
> 
> 
>> On Thu, 3 Aug 2023 at 15:56, Christofer Dutz  
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> as there seems to be general consent on this, I have taken the liberty to 
>>> prepare the PRs for this:
>>> https://github.com/apache/infrastructure-github-event-notifier/pull/12
>>> https://github.com/apache/infrastructure-github-discussions-notifier/pull/2
>>> However, have I marked them as DRAFT so they aren’t executed today.
>>> 
>>> I think it would make sense to send out an email first, notifying projects 
>>> about the coming changes and to define a date to which the changes will be 
>>> applied.
>>> 
>>> I’d be happy to prepare the email and send it out (once the 72h for this 
>>> POLL are over).
>>> 
>>> Chris
>>> 
>>> Von: Christofer Dutz 
>>> Datum: Mittwoch, 2. August 2023 um 09:47
>>> An: Volkan Yazıcı 
>>> Betreff: AW: [POLL] Should we ask Infra to change the defaults used to 
>>> generate GitHub integration email subjecs?
>>> Still giving this a bit more time (72 hours in total) as we usually do 
>>> things.
>>> But yeah … I guess as soon as that time is over, I’ll create an infra 
>>> ticket.
>>> 
>>> Chris
>>> 
>>> 
>>> Von: Volkan Yazıcı 
>>> Datum: Mittwoch, 2. August 2023 um 09:39
>>> An: Christofer Dutz 
>>> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
>>> generate GitHub integration email subjecs?
>>> Check. Is there (or will there be) an INFRA ticket that I can follow the 
>>> implementation progress?
>>> 
>>> On Wed, Aug 2, 2023 at 9:28 AM Christofer Dutz 
>>> mailto:christofer.d...@c-ware.de>> wrote:
>>> Hi Volkan,
>>> 
>>> well I won’t be doing anything … also is this not really a vote (as we 
>>> didn’t know if this is something we actually are allowed or able to vote 
>>> on).
>>> So my plan is to show this thread to Infra to show that there’s general 
>>> support for the proposal.
>>> 
>>> I really hope they won’t let me jump another hoop, asking me to bring this 
>>> to a vote on Members@.
>>> 
>>> But sure I think this is worth sending out to committers@ or similar list, 
>>> which will make a wide range of people be informed.
>>> 
>>> Chris
>>> 
>>> 
>>> Von: Volkan Yazıcı mailto:vol...@yazi.ci>>
>>> Datum: Mittwoch, 2. August 2023 um 09:22
>>> An: Christofer Dutz 
>>> mailto:christofer.d...@c-ware.de>>
>>> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
>>> generate GitHub integration email subjecs?
>>> [PM'ing to avoid derailing the vote thread.]
>>> 
>>> Christofer, in the email where you will announce the result, would you mind 
>>> also sharing when the change will take place, please? This will help users 
>>> to know when they shall expect the changes.
>>> 
>>> Kind regards.
>>> 
>>> On Wed, Aug 2, 2023 at 8:46 AM Christofer Dutz 
>>> mailto:christofer.d...@c-ware.de>> wrote:
>>> Well,
>>> 
>>> stating the obvious, I’ll add my +1 ;-)
>>> 
>>> And yes Craig, I said the defaults … if you have explicitly configured your 
>>> .asf.yaml subjects, they are left unchanged.
>>> 
>>> Chris
>>> 
>>> 
>>> Von: Richard Zowalla mailto:rich...@zowalla.com>>
>>> Datum: Mittwoch, 2. August 2023 um 08:10
>>> An: dev@community.apache.org<mailto:dev@community.apache.org> 
>>> mailto:dev@community.apache.org>>
>>> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
>>> generate GitHub integration email subjecs?
>>> +1
>>> 
>>> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk 
>>> mailto:ja...@potiuk.com>>:
>>>> +1
>>>> 
>>>> On Wed, Aug 2, 202

Re: [PR] Update mailing-lists.md (comdev-site)

[Craig Russell]

Hi Chris,

I really appreciate your dedication, hard work, and perseverance in making this 
happen.

Best,
Craig

> On Aug 17, 2023, at 04:11, chrisdutz (via GitHub)  wrote:
> 
> 
> chrisdutz merged PR #127:
> URL: https://github.com/apache/comdev-site/pull/127
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: Requests for comdev membership

[Craig Russell]

> On Sep 3, 2023, at 04:36, Shane Curcuru  wrote:
> 
> Craig L Russell wrote on 9/1/23 2:28 PM:
>> I recently sent a PR for the site and nothing happened. No one reviewed. No 
>> one commented.
> 
> Link?  There's only one open PR (not from you), and the most recent closed PR 
> you submitted was closed quickly by sebb.
> 
> https://github.com/apache/comdev-site/pull/124
> 
> Just trying to ensure we're all talking about the same repo.

Yes, the repo I was referring to is comdev-site. I'm sorry I mischaracterized 
the months-long process of updating the page to improve the process of adding 
new committers. 
> 
> The README.md does provide fairly decent description about how to make 
> changes, although we don't define CTR or RTC or other policies.  I'd opt for 
> CTR since getting volunteers interested is more important than avoiding 
> potential mistakes.
> 
> Personally, I'd like to see us adopt a modified Incubator concept, where any 
> Apache committer can simply asked to be made a ComDev committer, and the PMC 
> will turn on commit for ComDev repos too.  That should be sufficient for most 
> cases, without needing to special case our repos for all committers ever.

This sounds like it is worth trying. 

Craig
> 
> -- 
> - Shane
>  ComDev PMC
>  The Apache Software Foundation
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: projects.a.o "maintainer" field

[Craig Russell]

I think projects would just put  as the name and dev@project... as the 
mail address. But there is already a mail-list field so it seems redundant.

So I agree that we should drop "maintainer".

Craig

> On Sep 7, 2023, at 10:08, rbo...@rcbowen.com wrote:
> 
> 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
> 

Craig L Russell
c...@apache.org


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

[Craig Russell]

I thought that a few folks responded to sebb earlier in the thread. Repeating 
an earlier post does not make it a new post.

Changing defaults will not affect people who have changed their own project 
settings. And if they are happy with the defaults to the extent that they 
complain about the defaults changing for the better, I will split the bar tab 
with you

Craig

> On Sep 29, 2023, at 09:09, Christofer Dutz  wrote:
> 
> As it was pointed out that nobody responded to this, let me do so:
> 
> We have provided docs for quite some time … nothing really has changed as 
> many projects are on a steep decline on using their lists.
> These proposes changes have seen a very dominant support by most people who 
> expressed their thoughts here.  You are currently the only person actively 
> objecting.
> 
> We are trying to improve things.
> We are also not forcing anything on anyone … whoever wants things to stay the 
> way they were, we provided all the information upfront to how they can keep 
> things the way they were.
> 
> Let’s make a one-sided bet: if there are more people complaining about the 
> change after it happened than are expressing to be happy with them, I’ll 
> invite you to a beer?
> 
> Chris
> 
> 
> 
> Von: sebb 
> Datum: Freitag, 4. August 2023 um 11:21
> An: dev@community.apache.org 
> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
> generate GitHub integration email subjecs?
> NAK - I don't think the defaults should be changed; instead provide
> docs on how to do so
> Don't force projects to change if they don't want to
> 
> On Wed, 2 Aug 2023 at 07:46, Christofer Dutz  
> wrote:
>> 
>> Well,
>> 
>> stating the obvious, I’ll add my +1 ;-)
>> 
>> And yes Craig, I said the defaults … if you have explicitly configured your 
>> .asf.yaml subjects, they are left unchanged.
>> 
>> Chris
>> 
>> 
>> Von: Richard Zowalla 
>> Datum: Mittwoch, 2. August 2023 um 08:10
>> An: dev@community.apache.org 
>> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
>> generate GitHub integration email subjecs?
>> +1
>> 
>> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk :
>>> +1
>>> 
>>> On Wed, Aug 2, 2023 at 2:15 AM Craig Russell  wrote:
>>>> 
>>>> Hi Christofer,
>>>> 
>>>> As long as projects with their own settings can continue to use them, I'm
>>>> 
>>>> +1
>>>> 
>>>> to change the defaults for all projects. If the projects don't like being 
>>>> able to use their lists again, they can always go back to what they had 
>>>> before.
>>>> 
>>>> Thanks,
>>>> Craig
>>>> 
>>>>> On Aug 1, 2023, at 05: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 t

Re: Community docathon in Halifax?

[Craig Russell]

Shane and Rich,

All of that

> On Oct 6, 2023, at 05:49, rbo...@rcbowen.com wrote:
> 
> 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
> 

Craig L Russell
c...@apache.org


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

Re: reporter.a.o 502 Proy error

[Craig Russell]

I believe this is due to an outage on the whimsy machine that was reported by 
Daniel Gruno at 06:50 PST today...

> On Jan 1, 2024, at 20:47, Benchao Li  wrote:
> 
> For me, it's "503 Service Unavailable".
> 
> On 2023/12/31 19:07:49 Gary Gregory wrote:
>> For me it says "Loading base data" and that's it.
>> 
>> Gary
>> 
>> On Sun, Dec 31, 2023, 5:24 AM Daniel Sahlberg 
>> wrote:
>> 
>>> Hi,
>>> 
>>> https://reporter.apache.org says "Notification [object Response]" after a
>>> timeout.
>>> 
>>> It seems to be a call to https://reporter.apache.org/api/overview
>>> returning
>>> a 502 Proxy error
>>> 
>>> Kind regards,
>>> Daniel Sahlberg
>>> (Serf and Subversion PMC)
>>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: [WG: Sharpeners] Propose: milder name

[Craig Russell]

Hi Gary,

I like the name "Advisor" since to me it has no negative associations.

By the way, in reviewing project board reports, I often see projects that 
recognize and report on areas of improvement, and that would welcome having an 
Advisor try to help them.

Craig

> On Feb 18, 2024, at 08:19, Gary Gregory  wrote:
> 
> Hi All,
> 
> Based on 
> https://github.com/rbowen/comdev-working-groups/tree/main/wg-sharpeners#readme
> 
> I read:
> 
> - volunteers who come alongside a PMC to offer an outsider's
> perspective on the project, and advice to build their community.
> - subscribe to the project's mailing lists and mostly listen
> - do not have any authority over the PMC
> - All feedback must be a polite, positive, actionable suggestion, not
> merely a criticism or a "you're doing it wrong." You must suggest what
> the community should do, providing links to policy or best practice
> documents where applicable. Simply criticising is not welcome.
> 
> All of this sounds to me like an advisory role where advisory is
> "having or consisting in the power to make recommendations but not to
> take action enforcing them."[1]
> So I'd go with "PMC Advisor". It's not cute or clever, it's even
> bland, but I understand it, ;-)
> 
> Gary
> [1] https://www.google.com/search?q=define+advisory
> 
> On Sun, Feb 18, 2024 at 4:08 PM Rich Bowen  wrote:
>> 
>> 
>> 
>>> On Feb 18, 2024, at 10:02 AM, Gary Gregory  wrote:
>>> 
>>> I've never heard of someone being called a "sharpener"; I've used a
>>> knife sharpener and a pencil sharpener ;-) ... it feels like a stretch
>>> here.
>>> 
>>> In general, I prefer names that simply describe intent instead of
>>> cuteness/cleverness, especially in an international context where I
>>> find it beneficial to use words that make sense if you have to look
>>> them up.
>> 
>> Cool. Y’all come up with a name, and I’ll swap it out.
>> 
>> 
>> 
>> -
>> 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
> 

Craig L Russell
c...@apache.org


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

Web site checker needs help

[Craig Russell]

While reviewing some of the project reports for the board meeting, I use the 
tool
https://whimsy.apache.org/site/
to help me understand the projects' conformance with policy.

I noticed many "false negatives" and "false positives" that need attention. I 
believe that the tool is extremely useful but needs help. I have started to 
document and ask for feedback on some of the issues, but this is bigger than 
any one person can handle.

Is it worth creating a new community-working-group-site-check to document the 
issues with the tool? Perhaps a better name would help...

Craig L Russell
c...@apache.org


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

Reporter tool for board reports needs some love

[Craig Russell]

Hi,

Is there anyone who can take a look at the Reporter tool that many projects 
rely on to help create board reports?

A number of projects have commented that the statistics seem to be in conflict 
with reality.

Thanks,
Craig

Craig L Russell
c...@apache.org


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

Re: "Maintainer" as an alias of PMC Member?

[Craig Russell]

I totally get the problem. I think if we can find a suitable title for PMC 
Member we could socialize it in a few years. Should have done this years ago.

But "Maintainer" does not do it for me. Keep looking...

Craig

> On Mar 23, 2024, at 01:47, tison  wrote:
> 
> Hi,
> 
> Random thought.
> 
> You may find people not a native English speaker keep calling a PMC Member
> of Apache Foo "Foo PMC".
> 
> We correct it so many times and spread the knowledge on list. But the trend
> I observed doesn't change and IMO it's hopeless to change.
> 
> Since people tend to use a short ref and "committer" gives a one-word
> identifier first image, I'm trying to propose officially alias "PMC Member"
> as "Maintainer" so that our wording is aligned.
> 
> What do you think?
> 
> Best,
> tison.

Craig L Russell
c...@apache.org


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

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 03:05, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>> ...Many ASF projects do not have a code of conduct, and push this up to the 
>> Foundation. This mostly seems
>> to work, in practice, most of the time, but the public *perception* is just 
>> that they don’t have one...
> 
> I think this should be handled like
> https://security.apache.org/projects/ : projects CAN have their own
> code of conduct page and contact address, and if they don't they MUST
> point to the ASF's page and contact address

I agree. I'll volunteer to be part of the working group to make this happen.

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

Craig L Russell
c...@apache.org


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

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 06:31, Rich Bowen  wrote:
> 
>> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
>> wrote:
>> 
>> Hi,
>> 
>> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>>> ...Many ASF projects do not have a code of conduct, and push this up to the 
>>> Foundation. This mostly seems
>>> to work, in practice, most of the time, but the public *perception* is just 
>>> that they don’t have one...
>> 
>> I think this should be handled like
>> https://security.apache.org/projects/ : projects CAN have their own
>> code of conduct page and contact address, and if they don't they MUST
>> point to the ASF's page and contact address
> 
> While I agree in principle, ComDev cannot say MUST to any project. We are a 
> PMC, not a Board/President committee, and act only in an advisory capacity.
> 
> (I know you know this, but it bears reminding and repeating this for others 
> watching this conversation.)

I suppose if the board wants to take some action it could pass a resolution...

Craig

> 
> —Rich
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org 
> 
> For additional commands, e-mail: dev-h...@community.apache.org 
> 
Craig L Russell
c...@apache.org

Re: [WG: Code of conduct] Proposal

[Craig Russell]

> On Jun 11, 2024, at 07:17, Rich Bowen  wrote:
> 
>> 
>> On Jun 11, 2024, at 9:55 AM, Craig Russell  wrote:
>> 
>> 
>> 
>>> On Jun 11, 2024, at 06:31, Rich Bowen  wrote:
>>> 
>>>> On Jun 11, 2024, at 6:05 AM, Bertrand Delacretaz  
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On Mon, Jun 10, 2024 at 3:33 PM Rich Bowen  wrote:
>>>>> ...Many ASF projects do not have a code of conduct, and push this up to 
>>>>> the Foundation. This mostly seems
>>>>> to work, in practice, most of the time, but the public *perception* is 
>>>>> just that they don’t have one...
>>>> 
>>>> I think this should be handled like
>>>> https://security.apache.org/projects/ : projects CAN have their own
>>>> code of conduct page and contact address, and if they don't they MUST
>>>> point to the ASF's page and contact address
>>> 
>>> While I agree in principle, ComDev cannot say MUST to any project. We are a 
>>> PMC, not a Board/President committee, and act only in an advisory capacity.
>>> 
>>> (I know you know this, but it bears reminding and repeating this for others 
>>> watching this conversation.)
>> 
>> I suppose if the board wants to take some action it could pass a resolution…
> 
> 
> The work that this working group needs to do is, I believe, a prerequisite to 
> asking the board to make such a resolution. If you feel differently, don’t 
> wait for me, but that’s how I see things.

We are in agreement. The board should act only after there is agreement on a 
proposal that has been carefully reviewed.

Craig

> 
> —Rich (speaking with my fictional “hat” as a Member, not as a Director)

Craig L Russell
c...@apache.org

Re: [apache/comdev-site] Refactor of "new pmc member" doc and templates (PR #189)

[Craig Russell]

I find it very difficult to deal with policy issues via GitHub PR comments.

Could we please have a separate thread on the dev list where we discuss issues 
like:

What does consensus mean? (I think elsewhere it is lazy approval)

Can PMC votes be vetoed (by a single -1 vote)?

Can committer votes be vetoed  (by a single -1 vote)?

If needed, I will volunteer to start such discussion...

Craig

> On Oct 29, 2024, at 09:35, Rich Bowen  wrote:
> 
> @rbowen  pushed 1 commit.
> 
> 9409c82 
> 
>  vote outcome definition
> —
> View it on GitHub 
> 
>  or unsubscribe 
> .
> You are receiving this because you are subscribed to this thread.
> 

Craig L Russell
c...@apache.org

Re: [apache/comdev-site] Refactor of "new pmc member" doc and templates (PR #189)

[Craig Russell]

Shane, Rich,

I think we are agreed on the points that I raised. The documentation in the 
advice/templates did conflict with policy on a number of issues.

My concern was the comments scattered through the PR blizzard that made it seem 
that some folks did not understand the precedent and that Rich was correcting 
wrong information.

I appreciate the work that Rich is putting in here to make the advice 
consistent with policy.

Warm regards,
Craig


> On Oct 30, 2024, at 05:52, Rich Bowen  wrote:
> 
> 
> 
>> On Oct 29, 2024, at 10:25 PM, Craig Russell  wrote:
>> 
>> I find it very difficult to deal with policy issues via GitHub PR comments.
>> 
>> Could we please have a separate thread on the dev list where we discuss 
>> issues like:
>> 
>> What does consensus mean? (I think elsewhere it is lazy approval)
>> 
>> Can PMC votes be vetoed (by a single -1 vote)?
>> 
>> Can committer votes be vetoed  (by a single -1 vote)?
>> 
>> If needed, I will volunteer to start such discussion…
> 
> 
> 
> Since Shane has already responded in this thread …
> 
> This is very clear to me, on three points - documentation, precedent, and 
> intent. From where I sit, the doc I was editing was simply wrong.
> 
> The doc - https://apache.org/foundation/voting.html 
> <https://apache.org/foundation/voting.html> - says simple majority for 
> procedural votes. And while the doc can certainly be clarified, and 
> “procedural” is not defined, PMC/Committer election clearly does not fit into 
> the other categories in that doc.
> 
> The precedent - since the beginning, and in every project I’ve observed or 
> been part of, PMC and Committer elections are not veto-able. Only code 
> changes are veto-able. This has been seen both in practice, and in the many 
> threads about this on members@ over the years. Only code changes can be 
> vetoed, and even then, only with a technical reason. There can be not 
> technical reason for a PMC/Committer election veto.
> 
> The intent - this is more subjective, but from where I sit, allowing a single 
> PMC member to veto the election of a new Committer/PMC member would (could) 
> lead directly to a BDFL situation, which is antithetical to our ethos and 
> tradition. It would (could) result in a single PMC member exerting “founder” 
> status and having complete control over who joined the project. We already 
> see projects where one voice is “more equal than others”, and codifying this 
> in the ability to override a majority of the PMC would be chilling to 
> community voice and growth.
> 
> So, to me, this is not a question of me challenging or changing policy. I was 
> correcting a factual error in a document that was supplementary to the 
> official doc. This doc is only intended to augment the official policy doc - 
> https://apache.org/foundation/voting.html 
> <https://apache.org/foundation/voting.html> - with best practice advice, not 
> alter or modify that official doc.
> 
> If we want to start a new thread on this, it probably goes on members@ or 
> board@, and I’d be glad to reiterate the above there.
> 
> —Rich

Craig L Russell
c...@apache.org

Re: Consensus? we do have a glossary (was:Refactor of "new pmc member" doc...)

[Craig Russell]

I would be in favor of removing "consensus" from our documentation.

It has a general meaning of "group agreement" which is not how we use it here. 

I would propose using "unanimous" instead of "consensus" as there seems to be 
no ambiguity about unanimity. 

And then "majority approval" which is "more +1 than -1 votes".

So we would have these with the Apache three vote minimum:

Procedural votes (new PMC members, new committers) require majority approval 
with at least three +1 votes.

Code changes require unanimous approval with at least three +1 votes.

While I really dislike changing history, "consensus" has been a bad term for so 
long...

Craig


> On Oct 31, 2024, at 07:04, Bertrand Delacretaz  wrote:
> 
> On Thu, Oct 31, 2024 at 1:57 PM Rich Bowen 
> wrote (on a GitHub page):
>> 
>> I think possibly one of the points of confusion here is the use of the word 
>> "consensus",
>> which has been a point of confusion for years, since that word has several 
>> substantially different uses
> 
> We do have an ASF glossary at
> https://www.apache.org/foundation/glossary, which we might improve and
> which we should IMHO point to more often.
> 
> Or maybe create an additional glossary on the comdev website, and link
> both pages for completeness.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Craig L Russell
c...@apache.org


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

Re: [ALC] Request to establish ALC in Taipei

[Craig Russell]

+1 (clr) for the ALC in Taipei

Craig


> On Apr 3, 2025, at 08:21, Chia-Ping Tsai  wrote:
> 
> hi All,
> 
> I'm an Apache Member (Apache ID: chia7712), and I've led the local
> open-source community, 源來適你/opensource4you [1], for two years. We've
> successfully fostered contributions to various Apache projects, including
> Apache Kafka, Apache YuniKorn, Apache Airflow, and Apache Gravitino,
> resulting in over 10 community members becoming Apache committers.
> 
> Leveraging the Apache Local Community (ALC) name would be a valuable asset
> in our efforts to attract more contributors to open-source software
> projects.
> 
> Thanks,
> Chia-Ping
> 
> [1] https://www.facebook.com/opensource4you

Craig L Russell
c...@apache.org