[jira] [Commented] (COMDEV-422) Many crashes. Does not recover completely.

[Dave Fisher (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17859968#comment-17859968
 ] 

Dave Fisher commented on COMDEV-422:


[~rtrostel] you could also look at https://forum.openoffice.org/

> Many crashes. Does not recover completely.
> --
>
> Key: COMDEV-422
> URL: https://issues.apache.org/jira/browse/COMDEV-422
> Project: Community Development
>  Issue Type: Bug
> Environment: Operating system: Apache OpenOffice ver. 4.1.10
>Reporter: Ronald Trostel
>Priority: Major
>
> OpenOffice



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Re: Events calendar: help wanted

[Dave Fisher]

Hi Sebb,

That is a a good approach! Can a similar approach be used with 
https://calendar.google.com/calendar/u/0/embed?src=nerseigospses068jd57bk5...@group.calendar.google.com=UTC=1

Best,
Dave

> On Apr 18, 2024, at 4:47 PM, sebb  wrote:
> 
> OK, done.
> 
> https://community-calendar.staged.apache.org/ shows the calendar from
> a local copy of the calendar data.
> It should look exactly the same as the main site.
> 
> The plan is to fetch the calendar regularly using a GHA cron job
> (daily should be sufficient; it can always be triggered manually if
> necessary).
> 
> On Thu, 18 Apr 2024 at 15:44, sebb  wrote:
>> 
>> Note that we don't have a DPA with Google, and it is extremely
>> unlikely that we ever will, so the calendar on the main page also
>> falls foul of the ASF privacy policy.
>> 
>> Given that the data is static, it should not be too difficult to
>> extract the data when the site is built.
>> 
>> I'll try and look at that later.
>> 
>> On Thu, 18 Apr 2024 at 15:27, Rich Bowen  wrote:
>>> 
>>>> On Apr 18, 2024, at 10:25 AM, Raphael Bircher  
>>>> wrote:
>>>> 
>>>> Hi all
>>>> 
>>>> Just a notice: before we install an other tool only to have a Ical
>>>> function... confluence already has a calendar.
>>> 
>>> Can you possibly say more about this, or perhaps provide a link?
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Update Website Template (WAS: Help to get the Wayang project website in shape)

[Dave Fisher]

Hi Shane,

The Pelican ASF Template at https://github.com/apache/template-site is somewhat 
out of date as many contributors have contributed to ASF Pelican in the last 
two or three years. It would be good to revisit. I’m not sure I have the time 
or not, but that would great to update. One area in particular is as simple as 
adding updates to required privacy policies.

Best,
Dave

> On Feb 26, 2024, at 7:15 AM, tison  wrote:
> 
> Hi Shane,
> 
> It's under the list. See [1] and the referred thread. I'll try to
> submit a patch this week to add this information, including the
> pelican info. We'd later move the pelican template to this repo also
> in a dedicated branch and make it "just work".
> 
> Best,
> tison.
> 
> [1] https://github.com/apache/apache-website-template/issues/18
> 
> Shane Curcuru  于2024年2月26日周一 19:34写道：
>> 
>> tison wrote on 2/4/24 10:16 AM:
>>> Hi,
>>> 
>>> I finally find some time to prepare a demo for the new website template [1].
>> 
>> This is awesome; I love providing more default "just use this" templates
>> in various themes like this.
>> 
>> One question: why doesn't this also link (At least in the docs for each
>> readme maybe?) to the Infra-supported pelican template?  We should at
>> least point to that, since infra supports it and it provides a
>> python-managed template, in case people like that better than Jekyll/ruby.
>> 
>>   https://infra.apache.org/asf-pelican-gettingstarted.html
>> 
>> --
>> - Shane
>>   Member
>>   The Apache Software Foundation
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: [DISCUSS] Create a new repo for website template

[Dave Fisher]

Hi Tison,

Some future ideas.

(1) The web templates - html, js, css, and fonts are likely to be similar 
between the branches. (Well not all the js that docusaurus produces, but the 
site design will be similar.) This could lead to a branch with multiple 
designs. The question is what template language is used by docusaurus and 
jekyl? JINJA2?

(2) Once those two examples are complete. I think that an ASF Pelican example 
can be done as well. There are a number of examples like apache.org, 
http.apache.org, etc.

I’m following along and will have a look later on.

Best,
Dave

> On Feb 21, 2024, at 1:43 AM, tison  wrote:
> 
> Hi Chris,
> 
> Thanks you. Now we found a volunteer to improve the jekyll template and
> it's good :D
> 
> Daniel wrote:
>> This feels like we are over-engineering the solution to a simple
>> problem. Just use the existing website-template repository, have the
>> default branch be an empty branch with a README that tells you what the
>> different examples are, each in their own branch or directory.
> 
> I'm OK with this. And it seems a solution that no direct reasonable
> objection.
> 
> Although Sebb comments in the other thread [1] that such a Rip Down commit
> can be suboptimal due to the irrelevant history, with INFRA's help we can
> use a brand new README branch and make it the default.
> 
> I'm going to move forward with the development in docusaurus branch and
> recommend Chris to send the patch against the jekyll branch (I'll review it
> if you need).
> 
> For the master branch tech solution, I'm fine to wait a minutes to rip it
> down, switch with a brand new history, or any other suggestions.
> 
> Best,
> tison.
> 
> [1]
> https://lists.apache.org/thread/jjmb1jnl67rr5qnhdb047tms9ksd0yqq
> 
> 
> Christian Grobmeier 于2024年2月21日 周三16:07写道：
> 
>> Hello,
>> 
>> I love we are picking up this template idea again.
>> 
>> Previously I proposed to add some Docker files to help with quick setup.
>> I could add this straightaway to the Jekyll branch.
>> 
>> Does this sound like a good idea?
>> 
>> It could look like what I did for Privacy:
>> https://github.com/apache/privacy-website
>> 
>> Please let me know, then I will add it (or forget about it)
>> 
>> Kind regards,
>> Christian
>> 
>> On Tue, Feb 20, 2024, at 23:38, Willem Jiang wrote:
>>> From my recent experience, it could save the developer lots of time if
>>> they can work on the website's content by adding some markdown files
>>> directly.
>>> Following the website policy and turning the features of the website
>>> engine are one-time work. The ROI would be good if we could share
>>> these through the website template.
>>> 
>>> Thanks,
>>> 
>>> Willem Jiang
>>> 
>>> On Tue, Feb 20, 2024 at 8:20 PM tison  wrote:
>>>> 
>>>>> And/or just point to the source code of existing ASF websites which
>>>>> can serve as living examples.
>>>> 
>>>> You can check the original mailing list thread [1]. I recommend Fury as
>> an
>>>> example there because it's just started. Living examples can be
>> supplements
>>>> but customized a lot to prevent new podlings from catching up.
>>>> 
>>>> This is my initial motivation to create a template and even
>> self-contained
>>>> docs to share how to switch features while being compliant with ASF
>>>> policies :D
>>>> 
>>>> Best,
>>>> tison.
>>>> 
>>>> [1] https://lists.apache.org/thread/nzzvz0j6mlgfn4pldxg6988oqw20b0bx
>>>> 
>>>> 
>>>> Bertrand Delacretaz  于2024年2月20日周二 19:32写道：
>>>> 
>>>>> On Tue, Feb 20, 2024 at 10:45 AM Daniel Gruno 
>>>>> wrote:
>>>>>> ...Just use the existing website-template repository, have the
>>>>>> default branch be an empty branch with a README that tells you what
>> the
>>>>>> different examples are, each in their own branch or directory...
>>>>> 
>>>>> And/or just point to the source code of existing ASF websites which
>>>>> can serve as living examples.
>>>>> 
>>>>> And encourage people to add GitHub topics to their website
>>>>> repositories, so that queries like
>>>>> 
>>>>> 
>> https://github.com/search?q=topic%3Ahugo+org%3Aapache=Repositories
>>>>> 
>>>>> can give you a list of real live examples that use your favorite

Re: (apache-website-template) branch jekyll created (now f2f8a9e)

[Dave Fisher]

Hi Tison,

I’m following along. Infrastructure has a Pelican template site that is out of 
date: https://github.com/apache/template-site/

One approach is to find good examples of each build technique. If you look back 
at older projects you will see various historical waves of technique.

Best,
Dave 

> On Feb 20, 2024, at 3:48 PM, tison  wrote:
> 
> Hi Dave,
> 
> Thanks for picking up this commit. You may join the discussion at [1].
> 
> I have all the permission to follow what I want. But since
> apache-website-template is technically a foundation-wise repo and I'm
> a newcomer here, I'd like to listen to people's opinions before moving
> forward; especially there can be some arguments.
> 
> Best,
> tison.
> 
> [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8
> 
> Dave Fisher  于2024年2月21日周三 02:35写道：
>> 
>> From the commit email it looks like this repository belongs to the Incubator.
>> 
>>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote:
>>> 
>>> This is an automated email from the ASF dual-hosted git repository.
>>> 
>>> tison pushed a change to branch jekyll
>>> in repository 
>>> https://gitbox.apache.org/repos/asf/apache-website-template.git
>>> 
>>> 
>>> at f2f8a9e  Update download page template
>>> 
>>> No new revisions were added by this update.
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: cvs-h...@incubator.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: (apache-website-template) branch jekyll created (now f2f8a9e)

[Dave Fisher]

From the commit email it looks like this repository belongs to the Incubator.

> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> tison pushed a change to branch jekyll
> in repository https://gitbox.apache.org/repos/asf/apache-website-template.git
> 
> 
>  at f2f8a9e  Update download page template
> 
> No new revisions were added by this update.
> 
> 
> -
> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> For additional commands, e-mail: cvs-h...@incubator.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

[Dave Fisher]

Hi Rich,

Please find https://github.com/apache/comdev-working-groups/pull/10

Best,
Dave

> On Feb 19, 2024, at 12:00 PM, Rich Bowen  wrote:
> 
> Sounds like you’re in final agreement? Are y’all going to produce a PR to 
> swap out terms across the repo?
> 
> 
>> On Feb 18, 2024, at 4:52 PM, sebb  wrote:
>> 
>> +1 for Advisor.
>> 
>> Succinct and accurate.
>> 
>> On Sun, 18 Feb 2024 at 18:59, Dave Fisher  wrote:
>>> 
>>> Hi -
>>> 
>>> Thanks, Gary!
>>> 
>>> I agree. Advisors is really good. A PMC, or even a single PMC member, can 
>>> ask for advice when they have doubts. and unsolicited advice can be ignored 
>>> if not concise and actionable.
>>> 
>>> Best,
>>> Dave
>>> 
>>>> On Feb 18, 2024, at 8:19 AM, 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
>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 


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

Re: [WG: Sharpeners] Propose: milder name

[Dave Fisher]

Hi -

Thanks, Gary!

I agree. Advisors is really good. A PMC, or even a single PMC member, can ask 
for advice when they have doubts. and unsolicited advice can be ignored if not 
concise and actionable.

Best,
Dave

> On Feb 18, 2024, at 8:19 AM, 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
> 


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

Re: [WG: Sharpeners] Proposed: Escalation advice

[Dave Fisher]

Inline

> On Feb 16, 2024, at 10:28 AM, Rich Bowen  wrote:
> 
> Sorry, I managed to miss the second half of your email.
> 
>> On Feb 16, 2024, at 1:12 PM, Dave Fisher  wrote:
>> 
>>> https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md
>> 
>> It’s spelled “escalation”. In addition you use the term mentors here where 
>> there are already two other roles in the foundation that use this term.
>> 
> 
> Spelling fixed. Adjust URL accordingly.
> 
>> 1. In ComDev someone helping with GSoC is called a mentor.
>> 2. In the Incubator, Podlings have Mentors.
>> 
> 
> Is that a problem? Surely mentoring is the *primary* thing that ComDev does.

I’ve seen confusion over it, but if it is clearly defined that a sharpener is a 
type of mentor then that is very fine.

> 
> 
>> So, are “sharpeners” meant to be re-mentors? Who decides if a PMC needs 
>> “sharpening”?
> 
> Everyone needs mentors at different points in their lives. Incubation is a 
> process, with an end point. Projects do not cease needing mentoring once they 
> have graduated from the Incubator.
> 
> As to who decides,  well, this is a volunteer-driven process in a 
> volunteer-driven org, so I’d say it’s entirely voluntary. As discussed in the 
> conversation with Jarek earlier today, I think there are two possible entry 
> points. Either a PMC comes to ask for help, or an individual is interested in 
> a particular project community and shows up to learn about it, and sees 
> places where they could be strengthened. In this latter case, a very useful 
> data point would be reading board reports, and noticing the frequent times 
> that projects indicate that they need a little nudge on some issue or other.

Maybe we have sharpeners that have specialities like release policy, security, 
brand, vendor relations, etc and that could help PMCs decide whose mentorship 
would help.

Best,
Dave

> 
>> 
>>> 
>>> This is proposed advice around how and when an issue should be escalated. 
>>> In summary, the main advice is, don’t. The secondary advice is, if, and 
>>> only if, a project is *persistently unwilling* to acknowledge or address a 
>>> problem, and even then, only if you’ve got another Sharpener who agrees 
>>> with your assessment, would you *privately* tell the board about your 
>>> concern, and then *drop it.*
>> 
>> The above should be in the document somehow.
> 
> I thought I had. Please do feel free to improve my phrasing.
> 
>> 
>>> I’m sincerely hoping that this kind of explicit process/advice will help to 
>>> avoid the perception which I’m seeing from more than one place that this is 
>>> just a way for people to be policemen in our projects.
>> 
>> It does help.
>> 
>> I think that there should be a section that the sharpener’s advice and/or 
>> questions of the PMC should be consolidated into singular well thought out 
>> messages and not several disjoint emails where the threads lose context.
> 
> PRs welcome, although I’m not entirely sure what you mean here.
> 
>> 
>>> 
>>> Let me know what y’all think.
>> 
>> I may provide a PR over the weekend ….
> 
> Awesome. Thanks.
> 
> 


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

Re: [WG: Sharpeners] Proposed: Escalation advice

[Dave Fisher]

I have a couple of overarching comments.

A. Why “Sharpener”? I don’t really want to bike shed the name, but here are 
definitions:

1. a device or tool for making something sharper, esp. pencils or knives:
2. (Slang)  An alcoholic drink taken at the start of the day, or just before a 
meal.

I see you like the “sh” which can reinforce “shhh” as in confidential.

B. Is this process within the remit given to ComDev by the board?

> On Feb 16, 2024, at 8:50 AM, Rich Bowen  wrote:
> 
> I wrote a (proposed) thing:
> 
> https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md

It’s spelled “escalation”. In addition you use the term mentors here where 
there are already two other roles in the foundation that use this term.

1. In ComDev someone helping with GSoC is called a mentor.
2. In the Incubator, Podlings have Mentors.

So, are “sharpeners” meant to be re-mentors? Who decides if a PMC needs 
“sharpening”?

> 
> This is proposed advice around how and when an issue should be escalated. In 
> summary, the main advice is, don’t. The secondary advice is, if, and only if, 
> a project is *persistently unwilling* to acknowledge or address a problem, 
> and even then, only if you’ve got another Sharpener who agrees with your 
> assessment, would you *privately* tell the board about your concern, and then 
> *drop it.*

The above should be in the document somehow.

> I’m sincerely hoping that this kind of explicit process/advice will help to 
> avoid the perception which I’m seeing from more than one place that this is 
> just a way for people to be policemen in our projects.

It does help.

I think that there should be a section that the sharpener’s advice and/or 
questions of the PMC should be consolidated into singular well thought out 
messages and not several disjoint emails where the threads lose context.

> 
> Let me know what y’all think.

I may provide a PR over the weekend ….

Thanks,
Dave

> 
> — 
> Rich Bowen
> rbo...@rcbowen.com
> 


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

Re: [jira] [Commented] (COMDEV-543) Sharpeners use cases

[Dave Fisher]

To be clear Justin’s red flags are here: 
https://github.com/apache/comdev-working-groups/blob/main/wg-sharpeners/red-flags.md

> On Feb 14, 2024, at 11:46 AM, Phil Steitz  wrote:
> 
> I guess I am too late here, but fwiw, I agree strongly with Rich's
> comment.  I would much rather see the checklisty stuff incorporated into
> either the use cases or the main doc somewhere and not presented as "things
> 'we' are looking for".  I do not like at all the statement in the intro to
> the new doc,

I agree with Phil and would also add that this list of red flags is repetitive 
and is not a definitive list. It completely lacks nuance and you could 
reasonably bike shed what color of flag each of Justin’s signals deserves.

> "However, having an idea of what red flags we're looking for
> in a project can be a helpful way to start looking for places to mentor,
> and sharpen, our projects."
> 
> That is absolutely the wrong message to give.  Who is "we"?   This kind of
> thing sets the tone of the working group as some kind of external policing
> / inspecting function.  That will not help.

I’ve seen the impact of this list being to provide many disjoint concerns 
instead of carefully providing a list of concerns and assuming good intention 
from the PMC about one or more Members concerns. A scattershot approach is not 
respectful of the PMC.

> What *will help* is people showing up, listening and coming up with useful
> suggestions for how to solve problems that communities are facing.  In some
> cases, that may actually mean helping them explain why their way of doing
> things is perfectly fine.  I was shocked, for example, by "too many release
> candidates"  on the list of "red flags."   That is ridiculous, IMO, and
> nobody's business but the community.

My reaction as well. There can be many more RCs for x.y.0 than for x.y.4.

Regards,
Dave

> A sharpener certainly might help
> share experience about how other projects have handled packaging, testing
> and deployment issues, but just jumping in because a few releases have
> burned through a few RC numbers makes zero sense.
> 
> Phil
> 
> 
> 
> On Wed, Feb 14, 2024 at 7:39 AM Rich Bowen (Jira)  wrote:
> 
>> 
>>[
>> https://issues.apache.org/jira/browse/COMDEV-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817400#comment-17817400
>> ]
>> 
>> Rich Bowen commented on COMDEV-543:
>> ---
>> 
>> Added to doc in https://github.com/apache/comdev-working-groups/pull/2
>> 
>>> Sharpeners use cases
>>> 
>>> 
>>>Key: COMDEV-543
>>>URL: https://issues.apache.org/jira/browse/COMDEV-543
>>>Project: Community Development
>>> Issue Type: Improvement
>>> Components: Comdev
>>>   Reporter: Phil Steitz
>>>   Priority: Minor
>>>Attachments: use-cases.md
>>> 
>>> 
>>> Brain dump of ideas for sharpeners use cases
>> 
>> 
>> 
>> --
>> This message was sent by Atlassian Jira
>> (v8.20.10#820010)
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 


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

Re: VP Conferences changes

[Dave Fisher]

> On Nov 8, 2023, at 8:06 AM, Owen Rubel  wrote:
> 
> "So rather than worry about these sort if artefacts of institutionalisation
> or what bad KPIs \& wrong incentives can drive in a corporate world -- lets
> just make sure together that these conferences are what we want."
> 
> I kind of figured that was the point of speaking up; to let you know how
> vendor based conferences end up pushing out engineers.

You are not “wrong”, but within the ASF ecosystem this large problem already 
exists with some of our projects having vendor run “Summits”. It’s a different 
problem than who is managing Community over Code production. It’s a community 
health problem and an example of Foundation educational and governance 
improvements.

How can ComDev help ASF PMCs improve on that existing, very complex, and thorny 
issue?

Best,
Dave

> 
> Owen Rubel
> oru...@gmail.com
> 
> 
> On Wed, Nov 8, 2023 at 8:04 AM Dirk-Willem van Gulik 
> wrote:
> 
>> On 8 Nov 2023, at 13:03, Rich Bowen  wrote:
>> 
>>> Fyi, effective yesterday, I have stepped down as VP conferences. The
>>> responsibility for that role has passed to VP marketing, but
>> communication
>>> around conferences will still happen on the planners mailing list, as it
>>> has for many years.
>> 
>> Thanks for many years of undying service and making this event a community
>> one !
>>> 
>>> It's my hope to get a little more engaged on the side of the house,
>> which,
>>> of course, I've been trying to do for the last couple of years.
>> 
>> Amen to that. And as to those that worry about this marketing `takeover'
>> -- in the end of the day - the ASF, as a fully volunteer ran organisation,
>> relies on us, as individuals, to strike that balance that makes these
>> conferences so attractive to us volunteers & our community.  We, volunteers
>> vote with our feet !
>> 
>> So rather than worry about these sort if artefacts of institutionalisation
>> or what bad KPIs \& wrong incentives can drive in a corporate world -- lets
>> just make sure together that these conferences are what we want.
>> 
>> :)
>> 
>> Dw.
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 


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

Re: VP Conferences changes

[Dave Fisher]

Hi Rich,

Thank you for your decade plus work as VP, Conferences. In my experience you’ve 
done tremendous work and yet I appreciate your choosing your focus to be here 
on Community.

For those criticizing Rich’s personal decision as “bad” because “sales”. Please 
volunteer as a track chair. I was one and due to the way the selection process 
was run it was much harder to know who the speakers were. I’m not sure whether 
or not this helps with “vendors”. Regardless, volunteers are able to help if 
they are constructive.

Best,
Dave

Sent from my iPhone

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


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

Re: Community docathon in Halifax?

[Dave Fisher]

Sent from my iPhone

> On Oct 13, 2023, at 2:08 PM, Shane Curcuru  wrote:
> 
> A few of us talked briefly in Halifax, but didn't get time to do much work 
> together.  One key concept we discussed was defining the various audiences 
> that ComDev serves, so we can organize (and edit) content to make the most 
> sense to different kinds of readers.
> 
> One key audience I don't see us having much content for yet: managers, 
> marketers, engineers, etc. who are employed to work on ASF projects as 
> part(s) of their day job.  We've had a number of people who "get it" from 
> various vendors talk about this in the past, but I don't think we've ever 
> really had an organized effort to collect great examples of how vendors can 
> *positively* contribute in terms of their policies.
> 
> I met two people in Halifax who talked about exactly this kind of training at 
> their companies, and I also remember (at the time) a good slide deck and 
> training from Alan Gates way back when [1].  There have got to be other good 
> stories that some of the respectful vendor teams out there can tell that 
> would be good examples we could use to help other vendors understand how to 
> best work with our communities.
> 
> What's a good way to name this kind of audience, and how could we usefully 
> solicit some stories like this?

IIRC Sally had developed some material with a handful of vendors.

Best,
Dave

> 
> -- 
> - Shane
>  ComDev PMC
>  The Apache Software Foundation
> 
> [1] https://lists.apache.org/thread/bngv1vxfft501bcyqrydrc7dlr6gjf0q
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Fwd: ERROR: unexpected value 'go' for plc4x in http://plc4x.apache.org/plc4x-doap.rdf

[Dave Fisher]

Changes were made to project doap processing and now I get spammed with errors 
once a day.

Please fix this asap or I’ll have to unsubscribe to site-...@apache.org! Why is 
a Comdev process sending errors there?

Best,
Dave

Sent from my iPhone

Begin forwarded message:

> From: Projects 
> Date: September 8, 2023 at 7:10:37 PM PDT
> To: Site Development 
> Subject: ERROR: unexpected value 'go' for plc4x in 
> http://plc4x.apache.org/plc4x-doap.rdf
> Reply-To: site-...@apache.org
> 
> ERROR: unexpected value 'go' for plc4x in 
> http://plc4x.apache.org/plc4x-doap.rdf

Re: Centralise DOAPs?

[Dave Fisher]

Sent from my iPhone

> On Sep 8, 2023, at 7:11 AM, rbo...@rcbowen.com wrote:
> 
> On Thu, 2023-09-07 at 23:26 +0100, sebb wrote:
>> I think it would be worth considering setting up a central store for
>> DOAPs.
>> This was suggested in the past, but was rejected, I think mainly
>> because PMCs were expecting to have to make regular updates to DOAPs,
>> e.g. when releases are made, so wanted to keep them with the code.
>> 
>> It's a pain keeping the releases section of DOAPs up to date (even if
>> they are local to code).
>> Now that there is an automated releases listing, I wonder whether
>> there is any point keeping the info in the DOAP as well?
>> 
>> The rest of the fields in a DOAP rarely change, so it matters less if
>> the DOAP is stored in a different repo from the code to which it
>> relates.
>> 
>> If DOAPs were moved to a shared GitHub repo, I think it would be much
>> easier for maintenance purposes. Some issues such as fixing an
>> incorrect repo URL or download page link could be dealt with by
>> anyone
>> with suitable karma.
>> 
>> Just a thought.
> 
> I'm a little torn on this one. It would certainly make it a lot easier
> for *me*, but at the expense of making it harder for the projects. We'd
> also have to go back around to every project to educate about this
> change, and address 100 different objections to the change
> 
> What would be cool is if Git had something equivalent to svn externals,
> so that we could have the best of both worlds. Maybe some day, Git will
> catch up to where svn was 10 years ago. ;-)
> 
> If, on the other hand, we are able to extract the frequently-changing
> stuff (ie, releases) from this data, and reduce it just to the seldom-
> changing stuff, as you suggest, this would be worth doing. It's not
> clear to me how big a lift that is, though.

Every release ever is at http://archive.apache.org/dist/ if it is not there 
then it’s not a release.

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

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

Re: Valid languages for projects.apache.org

[Dave Fisher]

I agree too. Mxml has been around for sometime but it is specific to certain 
PMCs and is more a file format like Yaml.

I wonder more about how we classify projects and project product based on 
whether or not the system consists of components and/or a service. Language 
makes more sense for describing components. But this a different discussion.

Best,
Dave

Sent from my iPhone

> On Sep 7, 2023, at 7:52 AM, Gary Gregory  wrote:
> 
> I agree with Sebb, MXML is an XML _vocabulary_.
> 
> Gary
> 
>> On Thu, Sep 7, 2023, 9:55 AM sebb  wrote:
>> 
>>> On Thu, 7 Sept 2023 at 13:36, Andrew Wetmore  wrote:
>>> 
>>> Apache Royale uses significant numbers of MXML files in applications. Is
>>> that sufficiently different from XML that we should add it?
>> 
>> AFAICT MXML is a domain-specific superset of XML.
>> I don't think that deserves a separate language category.
>> 
>>> <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>>> 
>>> Virus-free.www.avast.com
>>> <
>> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
>>> 
>>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> 
>>> On Thu, Sep 7, 2023 at 8:31 AM Gary Gregory 
>> wrote:
>>> 
>>>> ODBC and JDBC are APIs, not languages, I hope we can all agree on that.
>>>> 
>>>> The "L" in XML and SQL stand for Language, so... ;-)
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>> On Thu, Sep 7, 2023, 7:24 AM sebb  wrote:
>>>> 
>>>>> There are currently a few project DOAPs which use languages not in
>> the
>>>>> current valid list.
>>>>> 
>>>>> These are:
>>>>> 
>>>>> BASH/Bash
>>>>> Freemarker
>>>>> Haxe
>>>>> JDBC
>>>>> ODBC
>>>>> SQL
>>>>> XML
>>>>> 
>>>>> Whilst we could add Bash, we might then need to add all the other
>>>>> Shell languages.
>>>>> Freemarker is a templating language; could be added
>>>>> Haxe is a valid language; could perhaps be added
>>>>> JDBC and ODBC are not languages; I think they should be dropped from
>>>>> the classification.
>>>>> SQL and XML can perhaps be considered languages
>>>>> 
>>>>> WDYT?
>>>>> 
>>>>> Sebb
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>>>> For additional commands, e-mail: dev-h...@community.apache.org
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Andrew Wetmore
>>> 
>>> Editor, Moose House Publications <https://moosehousepress.com/>
>>> Editor-Writer, The Apache Software Foundation <https://apache.org/>
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 


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

Re: Requests for comdev membership

[Dave Fisher]

I think it is easier than you think.

1. People who want to make changes submit PRs (if it’s svn does Comdev have a 
process?)

2. Like any PMC, members and committers approve and merge PRs.

What’s the problem? Not enough PR review?

Yurking and all the best,
Dave

Sent from my iPhone

> On Aug 16, 2023, at 8:50 PM, Rich Bowen  wrote:
> 
> It seems to me that the recent requests for comdev membership are symptoms
> of broken process. I understand that this is necessary to get things done,
> but the fact that someone has to be a comdev member in order to edit the
> website is broken. I am not sure what the way forward is here, but if
> someone has some insight into how things work, and can suggest a more
> reasonable way around this than making contractors comdev members, I would
> be much appreciative
> 
> Rich


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

Re: Changing the defaults for GitHub generated email titles?

[Dave Fisher]

Sent from my iPhone

> On Jun 30, 2023, at 2:14 AM, Christofer Dutz  
> wrote:
> 
> Hi Bertrand,
> 
> In general, I would agree, but the problem is that we currently have a very 
> large number of unreadable lists.
> This is what I’m generally trying to fix. Some projects responded with “If 
> the defaults are the ways they are, they probably are for a reason … we’ll 
> stick with the defaults” … problem is I am very sure that there never was a 
> discussion on how these defaults should look and that they are more that way 
> for implementation reasons and not community reasons.

I know that infra did have discussions and had reasons that were not just 
tooling. I recall asking about subject length a few years ago. I’m not going to 
look right now. You might want to ask them.

Best,
Dave

> 
> Chris
> 
> 
> Von: Bertrand Delacretaz 
> Datum: Freitag, 30. Juni 2023 um 11:11
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> Hi,
> 
>> On Fri, Jun 30, 2023 at 9:50 AM Christofer Dutz
>>  wrote:
>> ...I had many discussions with folks at infra about changing the defaults, 
>> but generally
>> met opposition. The general argument was, that there would be bots that 
>> automatically
>> consume these emails and these would be confused if we changed the 
>> defaults...
> 
> That's a totally valid concern IMO, but there might be two ways to
> change the defaults:
> 
> a) change for all lists which don't have specific settings
> b) change for newly created lists from now on
> 
> If b) is possible I think that's much safer, and ideally projects can
> opt-in to switch existing lists.
> 
>> ...Quite a number of projects have adopted these settings:
>> Like StreamPipes: 
>> https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M
> 
> This looks nice to me, which is unsurprising, as people know I'm a big
> fan of Tags Everywhere ;-)
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org


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

Re: Reviewers Needed for Community Over Code NA Community Track

[Dave Fisher]

Hi Sharan,

I’m already a reviewer for the Streaming track. I’m happy to review the 
Community track as well.

Best,
Dave

Sent from my iPhone

> On Jun 28, 2023, at 12:48 PM, Sharan Foga  wrote:
> 
> Hi Michel
> 
> Thanks for volunteering to help. It is not very complicated so I am sure you 
> will be fine. I will add you to our list of reviewers.
> 
> Thanks
> Sharan
> 
>> On 2023/06/28 19:37:29 Michel Sumbul wrote:
>> Hello Sharan,
>> I never did it but happy to help! :)
>> Michel
>> 
>> Envoyé depuis Yahoo Mail pour Android 
>> 
>>  Le mer., juin 28, 2023 à 20:28, Daniel Gruno a écrit: 
>>   On 2023-06-28 20:28, sharanf wrote:
>>> Hi Everyone
>>> 
>>> It's coming up to that time again... The CFP for Community Over Code 
>>> North America will be closing soon (on 13th July to be precise!) and we 
>>> are now looking for some volunteers to help us review the proposals. One 
>>> thing we are currently asking of the track reviewers is that they are 
>>> not planning to make a submission to the track they are reviewing.
>>> 
>>> If you are interested in helping out and haven't made a submission to 
>>> the Community track then please respond.
>> 
>> I volunteer as tribute!
>> 
>>> 
>>> Thanks
>>> Sharan
>>> 
>>> -
>>> 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

Re: [Proposal] ASF Fediverse/ActivityPub instance

[Dave Fisher]

> On Dec 8, 2022, at 6:44 PM, Greg Stein  wrote:
> 
> On 2022/12/08 20:30:02 Christian Grobmeier wrote:
>> ...
>> Bu t I mentioned, I get your point. Would you be less concerned with a 
>> domain like asf.social, since this is not an official domain? Assuming 
>> asf.social would be only for ASF community, but also allow "offical" 
>> accounts like press@asf.social?
> 
> By definition, asf.social is an official domain. ... If it is not, then it is 
> a trademark violation. One might argue the violation (good luck), but isn't 
> the GOAL to have an official domain to establish a trust level?
> 
> Trademarks, but more specifically Branding: has stated that the ASF will not 
> "grow" new domains, and that apache.org should be used. Simply to use 
> "asf.social" would require a clear exception grant from Branding.
> 
> Next: each hostname/service under apache.org must be owned by an Officer of 
> the Foundation. It was unclear for many years for many years who owned 
> www.apache.org and the annou...@apache.org mailing list. The Foundation 
> decided that is our public face, our public messaging, and should (thus) be 
> owned by the VP Marketing & Publicity. M also owns our Twitter account and 
> YouTube channel. By similar reasoning, M would own how an official hostname 
> used for Mastodon would be portrayed to the general public; especially if it 
> would become official messaging channel(s) for the Foundation.
> 
> Note: individual TLPs create their own accounts on third party services, such 
> as Twitter and Facebook, without consultation with M That is a bit 
> different from constructing an official [Mastodon] namespace for the 
> Foundation. Who owns *that* namespace? (IMO: M)
> 
> Should such an official hostname be desired, an Officer Owner will be 
> required. That is likely best discussed internally, but ENOCARE, really.

I agree with Greg’s statement above because that’s how it works.

Best,
Dave

> 
> Cheers,
> -g
> 
> ps. not speaking for Infra; just explaining how ownership of host/service 
> $foo works at the ASF
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: [DISCUSS] Crazy or good Idea?

[Dave Fisher]

> On May 11, 2022, at 11:43 AM, Matt Sicker  wrote:
> 
> A CCLA isn't sufficient for contributions at Apache, though. An ICLA
> is always required to be a committer, for example, regardless if every
> breath you take is copyrighted by your employer. A CCLA can be useful
> for documenting whether a corporation has explicitly approved various
> individuals they employ to contribute, but it's more of a comfort
> thing. If you read the ICLA, you'll see this bit:
> 
>   You represent that you are legally entitled to grant the above
>   license. If your employer(s) has rights to intellectual property
>   that you create that includes your Contributions, you represent
>   that you have received permission to make Contributions on behalf
>   of that employer, that your employer has waived such rights for
>   your Contributions to the Foundation, or that your employer has
>   executed a separate Corporate CLA with the Foundation.
> 
> The CCLA is optional because the ICLA already requires that you've
> gotten approval from any owners. The CCLA can formally document this,
> but it's already implied by the ICLA.

True, but (1) I was a brand new committer and (2) it made it clear that my 
employer could NOT change their mind arbitrarily.

I probably could have argued that the company that acquired my employer, my new 
employer, was bound by the CCLA … the ASF may only require an ICLA, but an 
individual may prefer that a CCLA is filed, That use case and language is in 
the ICLA BTW.

> or that your employer has
>   executed a separate Corporate CLA with the Foundation.


I’m not sure why you’re arguing this? Are CCLAs a burden to the Secretary?

> 
> On Wed, May 11, 2022 at 12:54 PM Dave Fisher  wrote:
>> 
>> When I first signed an ICLA in about 2008 I made sure that I had the company 
>> I worked for sign a CCLA that named individuals. This was for my protection 
>> otherwise my ASF work was work for hire.
>> 
>> Later that company was acquired and my position was senior enough that all 
>> of my work belonged to them.
>> 
>>> On May 11, 2022, at 10:37 AM, Matt Sicker  wrote:
>>> 
>>> Small point of clarification: only the ICLA matters at Apache since
>>> contributions are made by individuals. The CCLA is provided for
>>> companies so perplexed by this concept that they feel the need for
>>> more paperwork.
>>> 
>>> On Wed, May 11, 2022 at 4:36 AM Jarek Potiuk  wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> I guess my point about this is, that small startups usually have problems
>>>>> of getting contracts.
>>>>> 
>>>>> I can't count the occasions, where I generated leads at a conference.
>>>>> After the conference, when we were discussing moving forward, 95% of all 
>>>>> of
>>>>> these died because the customers can't do business with such small
>>>>> companies.
>>>>> 
>>>>> 
>>>> This is also my assessment of where  the problem is. I think building
>>>> relationships and finding customers in an OSS world is relatively easy if
>>>> you are transparent, honest, do your job well and you are open to speak,
>>>> you make sure you stand out of the crowd and you are generally proud of
>>>> what you do (yes Chris - those all things are about you too :D).
>>>> 
>>>> It's turning them into a regular invoice paid every month is where the
>>>> difficulty is.
>>>> 
>>>> However I think we need to really understand where the "can't do business"
>>>> comes from. My view on this:
>>>> 
>>>> 1) The businesses have established procurement processes and you have to
>>>> "fit" - in most cases there are a number of conditions:
>>>>   - you have to "be on the list" of the approved vendors
>>>>   - in many you have to sign certain agreements that you do not "child
>>>> labour", "bribery" etc. and similar thing (basically because public
>>>> companies have to report that their vendors are "ok" to the auditors
>>>>   - in many cases the business have to have someone to "sue" in case
>>>> there is a damage or have some other indemnification in place - (what if
>>>> the vendor does harm to our customers and we get sued)
>>>>   - there is also a check who is the beneficiary owner (money laundering)
>>>> W1-BEN forms in US when you have "individuals"
>>>>   - also - and this is more important recently - there is

Re: [DISCUSS] Crazy or good Idea?

[Dave Fisher]

When I first signed an ICLA in about 2008 I made sure that I had the company I 
worked for sign a CCLA that named individuals. This was for my protection 
otherwise my ASF work was work for hire.

Later that company was acquired and my position was senior enough that all of 
my work belonged to them.

> On May 11, 2022, at 10:37 AM, Matt Sicker  wrote:
> 
> Small point of clarification: only the ICLA matters at Apache since
> contributions are made by individuals. The CCLA is provided for
> companies so perplexed by this concept that they feel the need for
> more paperwork.
> 
> On Wed, May 11, 2022 at 4:36 AM Jarek Potiuk  wrote:
>> 
>>> 
>>> 
>>> I guess my point about this is, that small startups usually have problems
>>> of getting contracts.
>>> 
>>> I can't count the occasions, where I generated leads at a conference.
>>> After the conference, when we were discussing moving forward, 95% of all of
>>> these died because the customers can't do business with such small
>>> companies.
>>> 
>>> 
>> This is also my assessment of where  the problem is. I think building
>> relationships and finding customers in an OSS world is relatively easy if
>> you are transparent, honest, do your job well and you are open to speak,
>> you make sure you stand out of the crowd and you are generally proud of
>> what you do (yes Chris - those all things are about you too :D).
>> 
>> It's turning them into a regular invoice paid every month is where the
>> difficulty is.
>> 
>> However I think we need to really understand where the "can't do business"
>> comes from. My view on this:
>> 
>> 1) The businesses have established procurement processes and you have to
>> "fit" - in most cases there are a number of conditions:
>>- you have to "be on the list" of the approved vendors
>>- in many you have to sign certain agreements that you do not "child
>> labour", "bribery" etc. and similar thing (basically because public
>> companies have to report that their vendors are "ok" to the auditors
>>- in many cases the business have to have someone to "sue" in case
>> there is a damage or have some other indemnification in place - (what if
>> the vendor does harm to our customers and we get sued)
>>- there is also a check who is the beneficiary owner (money laundering)
>> W1-BEN forms in US when you have "individuals"
>>- also - and this is more important recently - there is a check if your
>> company does not fall into any of the sanctions imposed by the political
>> decisions
>>- there are a number of legal requirements (TAX Id registrations etc.)
>> 
>> Having an entity that is "known" to the customer and "big" and can provide
>> such guarantees is crucial otherwise it's a big effort to pass that step.
>> Here Both "Support Inc." and "Open Collective + ASF as fiscal host" - if we
>> can think about the two models, would likely work well. The "burden" of
>> verifying those is shifted to OpenCollective and ASF joint effort and I
>> think it should be feasible to put both OC and ASF as "accepted vendor
>> combo" for most big players. And for each player it would have to be done
>> once to enable all projects basically.
>> 
>> 2) We also have to remember that people who we contact as potential
>> customers often are not familiar with those processes - and even if they
>> "want" to work with you - this might be the first time they approach it and
>> it can take them MONTHS to get it sorted out.
>> I can - again - give a very good example. I mentioned "contract"
>> negotiations before - and it  is an interesting one. The prospective
>> customer people really wants to work with me. I really love what they do
>> and I have great contact there who is willing to take on all the complexity
>> of managing the OSS <> Company relations between me and the company - we
>> are also friends and worked together on a number of initiatives in the
>> project (successfully) and we both want to work together. And the manager
>> of my friend and his manager are fully supportive. And ~ 2 months ago the
>> joint statement was "we really want to start working together basically
>> next week". We still have no contract signed today. We know the price, we
>> know how much time I will focus on with the customer, we know what the
>> needs of the customer are. We know big parts of it will end up as good
>> community contributions. EVERYTHING is in place. But they never ever had a
>> contract with someone like me. I have a requirement that the contract from
>> the customer is explicit about my ICLA (and my self-owned company CCLA) and
>> this is with the lawyers of the company now.
>> 
>> Here - this is something that 1) will make easier - because (hopefully) we
>> could work out a template contract and having bigger entity (whether
>> Support Inc or OC + ASF Combo) we could probably have some established
>> "service" with all the documents prepared, and all the answers given and
>> even some guidance to our "partners" at the corporates on how 

Re: Naming/Branding: First Steps

[Dave Fisher]

That was someone’s opinion on a list. That is not official.

Sent from my iPhone

> On May 6, 2022, at 12:14 PM, me  wrote:
> 
> Our legal folks have responded (quickly!). 
> 
> I’m quoting the recommendation here: 
> 
> If someone wants to take ASF to court over this, we can  
> worry about it, then. Until then, there isn't really anything we can do  
> about it other than try to be as benign as possible toward those people  
> who might consider such litigation. 
> 
> 
> Benign as possible can be read in a number of different ways, depending on 
> how we are defining the scope (federally recognized Apache nations, all 
> Apache nations, all indigenous tribes, etc.) 
> 
> 
> 
> 1.) (Extreme 1) Do nothing. Without a registered complaint from the tribe, 
> this is analogous to an “If it ain’t broke don’t fix it, approach”.  
> 
> PRO: We don’t bring attention to a problem by communicating a scenario
> 
> CON: There has been communicated social impact complaints that aren’t being 
> addressed. There is a latent risk. 
> 
> 
> 
> 2.) (Extreme 2) Do everything. Just change the name and the license 
> proactively. This is a “full speed ahead” proactive effort. 
> 
> PRO: This removes any and all risk in perpetuity
> 
> CON: The level of effort is substantial, and it may exceed social 
> responsibility. 
> 
> 
> 
> 3.) Middle ground. Not sure what that is. 
> 
> 
> 
> Cheers!
> 
> Ed
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> From: Owen Rubel 
> Reply: dev@community.apache.org 
> Date: May 6, 2022 at 12:24:54
> To: dev@community.apache.org 
> Subject:  Re: Naming/Branding: First Steps  
> 
> Bravo. Brilliant.  
> 
> 
> Owen Rubel  
> oru...@gmail.com  
> 
> 
>> On Fri, May 6, 2022 at 7:26 AM me  wrote:  
>> 
>> Happy Friday/Saturday esteemed colleagues and collaborators!  
>> 
>> I kicked off the first steps by reaching out to the legal team to  
>> understand the risk/worst case scenario. I’m attempting to gain a better  
>> understanding to the question: “What if the choice is taken away from us,  
>> through litigation?”  
>> 
>> My thought process is the following:  
>> 
>> Irrespective of social climate, level of effort, etc. there is a worst  
>> case scenario represented by the ever present risk. Before we embark on any  
>> journeys of epic proportions for the greater good, it’s helpful to define  
>> the stakes and understand our primary responsibilities: our community.  
>> 
>> I think it’s a fair assumption that this will help level set conversations  
>> going forward, as well as to provide us a next question: “Given the defined  
>> risk, what is its magnitude?” (i.e. is it a 1 in a billion lightning  
>> strike, or a 50/50 coin flip).  
>> 
>> —  
>> 
>> That said, I think there is a derivative of Owen’s statements we have to  
>> consider.  
>> 
>> Asking a question to parties who haven't considered that question  
>> inevitably runs the risk of changing their perspective. If there is a gun  
>> to be jumped, this is most likely it. If I can make a request of those  
>> involved thus far, can you sleep on this and think about it? I think it’s  
>> something we need to consider internally so that any outreach is approached  
>> with care.  
>> 
>> It might be worth doing some internal research on Apache culture (nothing  
>> exhaustive, but enough for us to understand tribal values) before  
>> performing outreach (or in the extreme, from performing it altogether). At  
>> the very least this can help us navigate away from areas that may induce  
>> conflict, as well as to consider the wording of our inquiry.  
>> 
>> Walter, you seem to have a decent hold on the social impact. Do you have a  
>> resource you can reach out to? (Or is it something you’re willing to  
>> research to compile some facts?)  
>> 
>> 
>> 
>> From: me   
>> Reply: me   
>> Date: May 5, 2022 at 12:57:25  
>> To: dev@community.apache.org , Owen Rubel <  
>> oru...@gmail.com>  
>> Subject: Re: A way to keep the name  
>> 
>> Owen,  
>> 
>> You’re conflating different aspects of the circumstances.  
>> (Are you not from the US? Sorry for my ignorance. I’m just trying to  
>> better understand your position.)  
>> 
>> 1.) Business Risk.  
>> 
>> Our brand name has a causal relationship with an indigenous people.  
>> Regardless of our reputation or status, that indigenous people has the  
>> claim to the naming and branding based on existing legal precedent in the  
>> United States. This presents a business risk to the foundation and license.  
>> It would be in the best interest of the foundation to evaluate that risk.  
>> 
>> This problem exists whether it is dormant or active. I’m going to hand  
>> wave for brevity, but I’m happy to take this offline to explain it further.  
>> 
>> Yes, the ASF is a business. It may be a Non-Profit, Open Source Business,  
>> but we create products that are consumed.  
>> 
>> Profit and intent are irrelevant. There is no barrier (legally, socially  
>> or in business) that makes these concepts a 

Re: [DISCUSS] Crazy or good Idea?

[Dave Fisher]

> On Apr 20, 2022, at 12:31 PM, Sam Ruby  wrote:
> 
> On Wed, Apr 20, 2022 at 2:32 PM Christian Grobmeier
>  wrote:
>> 
>> [snip]. Actually, such a company would basically only need the blessing of 
>> the ASF and [snip]
> 
> Honest question: why?
> 
> Since the beginning of the ASF, there have been companies which
> provide commercial support for one or more of our products.  None of
> them have had any sort of blessing or exclusive rights.  The ASF
> doesn't care how they are structured or if they are for profit or
> non-profit.
> 
> We don't merely tolerate such organizations --as long as they don't
> make assertions about owning the products or having any sorts of
> exclusive rights, we welcome and celebrate them.  One such company was
> Covalent, and understanding what worked well and what didn't work so
> well might be helpful here.  I've added a few links at the bottom of
> this email.  By the way, the headline on the first link is something
> that would be considered very problematic - specifically the word
> "THE".

Exactly. This is an ongoing issue for some Vendors.
> 
> If there is a need for a blessing, the reasoning behind such a need
> will have to be explicitly enumerated.  As a practical matter, it is
> difficult to come to consensus with the membership, this doesn't feel
> like an operational matter which would fall under the purview of the
> president, so ultimately it is likely that it would have to be the
> board that provides any blessing.

We could encourage Support Co to review branding and press requirements to make 
sure they don’t cross the line into misrepresentation of their relationship 
with the ASF and any particular project.

> 
> Speaking as a board member: I'd like to encourage the idea of one (or
> more!) support organizations, but would like to push back on the idea
> that such organization(s) need any sort of blessing.  If I'm wrong,
> please convince me otherwise.

Agree. The only “blessing” would be if a concrete case is egregious. This is an 
ongoing task of PMCs, Press, and Brand.

> 
> - Sam Ruby
> 
> https://www.cmswire.com/cms/open-source-cms/covalent-is-the-apache-support-group-001328.php
> http://www.lannigan.org/Covalent_History_Covalent_Technologies.htm
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

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

[Dave Fisher]

> On Mar 4, 2022, at 10:28 AM, Jarek Potiuk  wrote:
> 
>> Definitely another good way to support projects.  I think 2. and 3.
>> originating in user companies can actually help foster vendor neutrality
>> as these companies are really just users.  Whether the people are
>> employees or contractors is not important.  What *is* important is that
>> they have time and mandate to contribute broadly to the project rather
>> than just trying to get specific features in.

This is a subtle and important point.
- how do vendors enable their individuals to upstream changes?
- how easy does the project make it for individuals to upstream their changes?

> 
> There is a huge difference actually.
> 
> Employees - almost by definition - cannot work for competitors at the
> same time. Individual contributors can.

That depends on the terms of employment. I’m employed currently and explicitly 
expected to contribute. This hasn’t always been the case.

> 
> As a contractor (and that also should be part of any other
> contributor's clause) I can work with multiple stakeholders - even
> competitors (and this is an important clause that I make sure in my
> contract).

There are reasons for competitors to co-operate.


> 
> Currently, as an independent contributor i have/had business relationship 
> with:
> 
> * Google
> * AWS
> * Astronomer
> 
> (And some more are coming). They are competitors, buti also they are
> cooperating on Airflow - so called "coopetition". This is next to
> impossible for an Employee to have several employment contracts with
> competitors at the same time.

This is how a vendor independent project ought to work.

Perhaps a review of 
https://blogs.apache.org/foundation/entry/the-apache-way-to-sustainable ?


> 
> Also it allows me to lead projects and initiatives, where there is a
> value brought by all those different stakeholders. Being independent
> and paid by all of those make it also easier for other stakeholders to
> join the efforts.
> 
> This is all extremely different to situations where the people
> contributing are employed by  a single Employer. That also works - of
> course, and there is nothing wrong with that. But it is very
> different.

Everyone’s situation is uniquely theirs.

All the best,
Dave

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


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

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

[Dave Fisher]

We can’t know the motivations of anyone funding a “tidelift” effort.

And we have trademarks / brand to help deal with misnamed vendor product.

PMCs have the same guarantees with vendors and funders - none.

Do we need a clearer statement about participation as individuals?

Do we need clarification about how a PMC can ask for help?

Trying to keep it simple.

All the best,
Dave

Sent from my iPhone

> On Mar 2, 2022, at 10:20 PM, Ralph Goers  wrote:
> 
> My experience with vendors that employee people to work on ASF projects is 
> that 
> they have their own internal processes that are separate from the ASF’s. For 
> example, 
> as part of their product they might deliver Apache Foo for Acme Bar. The 
> version they 
> ship might not exactly match what the ASF distributes. 
> 
> Tidelift doesn’t deliver a product so has no way to achieve this. 
> 
> That said, Tidelift certainly could provide resources to run the processes 
> they deem 
> necessary and get the folks they are paying to execute those. But any issues 
> that are 
> found would have to be resolved in the project, not in something Tidelift 
> distributes.
> 
> Ralph
> 
> 
> 
>> On Mar 2, 2022, at 6:10 PM, Dave Fisher  wrote:
>> 
>> The way this discussion is going makes me want to ask why should tidelift be 
>> any different from a vendor that pays individuals to work on ASF projects as 
>> part of their employment?
>> 
>> The same neutrality ought to apply. Why do we need to make a new 
>> classification?
>> 
>> All the best,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>>> On Mar 2, 2022, at 4:31 PM, Willem Jiang  wrote:
>>> 
>>> +1.
>>> It will make the maintainer's life easier with this collected information.
>>> When we bring the commercial support to the ASF project daily
>>> development,  we still need to follow certain rules to avoid the
>>> conflict with the Apache way we believed.
>>> 
>>> Willem Jiang
>>> 
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>> 
>>>> On Thu, Mar 3, 2022 at 1:08 AM Jarek Potiuk  wrote:
>>>> 
>>>> Thanks Roman for the initiative. +1 on it.
>>>> 
>>>> I think this might allow us to focus on what we (ASF) think is really
>>>> important and needed by the individuals who work on ASF projects, and set
>>>> our boundaries and limits their individual approach as well as clear limits
>>>> and boundaries for the organisations that would like to apply - and then
>>>> let any entity who wants to help to see how they can fit-in.
>>>> 
>>>> Happy to help with hashing it out.
>>>> 
>>>> J.
>>>> 
>>>> On Wed, Mar 2, 2022 at 3:30 PM Bertrand Delacretaz 
>>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Le mer. 2 mars 2022 à 15:19, Roman Shaposhnik  a
>>>>> écrit :
>>>>>> ...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...
>>>>> 
>>>>> +1, I like the idea!
>>>>> 
>>>>> -Bertrand
>>>>> 
>>>>> -
>>>>> 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
> 


-
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

[Dave Fisher]

The way this discussion is going makes me want to ask why should tidelift be 
any different from a vendor that pays individuals to work on ASF projects as 
part of their employment?

The same neutrality ought to apply. Why do we need to make a new classification?

All the best,
Dave

Sent from my iPhone

> On Mar 2, 2022, at 4:31 PM, Willem Jiang  wrote:
> 
> +1.
> It will make the maintainer's life easier with this collected information.
> When we bring the commercial support to the ASF project daily
> development,  we still need to follow certain rules to avoid the
> conflict with the Apache way we believed.
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
>> On Thu, Mar 3, 2022 at 1:08 AM Jarek Potiuk  wrote:
>> 
>> Thanks Roman for the initiative. +1 on it.
>> 
>> I think this might allow us to focus on what we (ASF) think is really
>> important and needed by the individuals who work on ASF projects, and set
>> our boundaries and limits their individual approach as well as clear limits
>> and boundaries for the organisations that would like to apply - and then
>> let any entity who wants to help to see how they can fit-in.
>> 
>> Happy to help with hashing it out.
>> 
>> J.
>> 
>> On Wed, Mar 2, 2022 at 3:30 PM Bertrand Delacretaz 
>> wrote:
>> 
>>> Hi,
>>> 
>>> Le mer. 2 mars 2022 à 15:19, Roman Shaposhnik  a
>>> écrit :
>>>> ...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...
>>> 
>>> +1, I like the idea!
>>> 
>>> -Bertrand
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>> 
>>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Thoughts on alternative communication channels for our communities

[Dave Fisher]

I want to go back to here with an idea.

> On Feb 18, 2022, at 5:38 AM, Bertrand Delacretaz  
> wrote:
> 
> -Project channels must be public, async, archived on ASF-owned
> services and searchable
> -Project channels must be usable with open source clients (hmmm..Slack?)
> -All decisions and votes must be documented on the project's mailing
> list, with links to the original discussion.

Pony Mail is a convenient way to review any mailing list. What if we require 
that any alternative like Slack or anything be able to produce either an email 
or an mbox and become a “pseudo mailing list"? If this is so then I think that 
given a Slack api it would possible to make use of some combination of Apache 
products to create the connector.

- Apache Pulsar could stream and has connectors.
- Apache POI has MBox capability.
- Apache James has mail capability.

I wonder if this is work that could be done in the Pony Mail podling.

All the Best,
Dave

Re: Question regarding Pony Mail

[Dave Fisher]

Yes, INFRA

Sent from my iPhone

> On Feb 15, 2022, at 8:44 PM, Maxim Solodovnik  wrote:
> 
> which project should I use? INFRA? :)
> 
>> On Wed, 16 Feb 2022 at 11:42, Zhiyuan Ju  wrote:
>> 
>> Hi,
>> 
>> How about creating a JIRA ticket?
>> 
>> Best Regards!
>> @ Zhiyuan Ju 
>> 
>> 
>> Maxim Solodovnik  于2022年2月16日周三 12:41写道：
>> 
>>> Hello,
>>> 
>>> For whatever reason Apache OAuth login doesn't work for me at
>>> https://lists.apache.org/
>>> (I even enabled 2FA, with no luck)
>>> 
>>> Which list should I contact to get help? :)
>>> 
>>> --
>>> Best regards,
>>> Maxim
>>> 
>> 
> 
> 
> -- 
> Best regards,
> Maxim


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

Re: The projects.apache.org site confuses basic principles

[Dave Fisher]

> On Feb 4, 2022, at 8:51 AM, Rich Bowen  wrote:
> 
> 
> 
> On 2/4/22 11:03, Dave Fisher wrote:
>> As I understand the ASF governance there are:
>> 1. Project Management Committees -> Projects. For example: Apache Logging.
>> 2. Products which are named artifacts from projects. For example: Apache 
>> Log4J
>> 3. Releases which are released artifacts of a project’s product. For 
>> example: Apache Log4J 2.17.1
> 
> The word "Product" means something different to many consumers of software. 
> We don't have products in that sense. We have projects and sub-projects.

(I came into Apache committership through Apache Jakarta POI. A project with 
too many sub-projects. I think that there is an important distinction between 
PMC and responsibility for Product vs. Project and sub-Project, but that’s an 
orthogonal issue.)

We do have products. The Brand committee makes the distinction between projects 
and products. See https://www.apache.org/foundation/marks/list/ for example.

> 
> I seem to remember struggling with this specific naming decision when the 
> projects.a.o site was first put up.

This was setup in the PRC, correct? (IIRC - PRC was split into comdev, 
conference, trademark, and press about 12 years ago)

> 
> That said ... patches welcome.

Sure - I included press@ because this site is an important reference for them.

> 
>> But on the https://projects.apache.org website the corresponding three items 
>> are called:
>> 1. Committees.
>> 2. Projects.
>> 3. Releases.
>> I suspect that this “confusion” is due to a combination of the split of the 
>> PRC committee and the former time of supper projects like Apache Jakarta.
>> This ought to be adjusted somehow because it leads to misunderstanding about 
>> responsibility.
>> All The Best,
>> Dave


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

The projects.apache.org site confuses basic principles

[Dave Fisher]

As I understand the ASF governance there are:

1. Project Management Committees -> Projects. For example: Apache Logging.
2. Products which are named artifacts from projects. For example: Apache Log4J 
3. Releases which are released artifacts of a project’s product. For example: 
Apache Log4J 2.17.1

But on the https://projects.apache.org website the corresponding three items 
are called:

1. Committees.
2. Projects.
3. Releases.

I suspect that this “confusion” is due to a combination of the split of the PRC 
committee and the former time of supper projects like Apache Jakarta.

This ought to be adjusted somehow because it leads to misunderstanding about 
responsibility.

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

Re: Tidelift

[Dave Fisher]

Jared, I like your descriptions! If you replace sponsor with vendor it should 
be very familiar to us all!

All the best,
Dave

Sent from my iPhone

> On Jan 22, 2022, at 4:12 PM, Jarek Potiuk  wrote:
> 
> Hey Roman,
> 
> I like it too. Happy to help too. I think it's not very far for Tidelift to
> adjust their model.
> 
> Maybe what could be helpful is to have some page/policy where we describe
> what can/cannot/should be from a Sponsor/PMC and contributor in exchange
> for money:
> 
> I see for example (I am not native speaker/legal, so this might be a poor
> trial - but might be a good start):
> 
> Sponsor:
> 
> * Respect the right of the individual to make the best decisions for the
> project even if they might not fully follow the Sponsor's guidelines
> * Might mention sponsoring particular individuals including
> mentioning their affiliation with the projects they sponsor (that might be
> somewhat controvertial)
> 
> PMC:
> 
> * Cannot promote/endorse the sponsor of individual's work on their official
> pages (if sponsorship is for code development, not resources)
> * Cannot commit to coding/standard requirements specified by the sponsor
> 
> The individual (no matter what merit the individual has):
> 
> * Can endorse and promote the sponsor as long as they make it as an
> individual and not PMC representative
> * Should have disclaimer to continue working on the project regardless of
> the sponsorship
> * Should act according to the
> https://www.apache.org/foundation/marks/responsibility.html for branding
> and endorsement when they act as PMC members especially (if they are PMC
> members)
> 
> Just initial thinking about it.
> 
> J.
> 
>> On Sun, Jan 16, 2022 at 8:36 PM Roman Shaposhnik 
>> wrote:
>> 
>> Jim said:
>> 
>>> IMO, the foundation and the project should do nothing associated with
>> this. It should neither encourage or condone it. In no way should we enter
>> into any agreement, contract, whatever, w/ Tidelift. If Tidelift wishes to
>> work independently and directly w/ people, that's fine. But having the ASF
>> and/or the project involved at any level should be disallowed.
>> 
>> This is exactly what I said on the LEGAL JIRA. So +1 to this framing. Now,
>> personally, I think Tidelift can be a great ally of Open Source in general
>> and as such I'm personally extremely willing to work with them to make sure
>> they come up with tweaks for their model that make sense to us and other
>> Open Source projects. More on that below:
>> 
>>> On Wed, Jan 12, 2022 at 7:56 AM Sam Ruby  wrote:
>>> 
>>> On Tue, Jan 11, 2022 at 4:50 PM Ralph Goers 
>>> wrote:
>>>> 
>>>> Hello all,
>>>> 
>>>> Recently the Logging Services PMC was approached by Tidelift offering
>> to
>>> provide monetary support either to the project or individual committers.
>> To
>>> obtain that sponsorship the project has to agree to the terms at
>>> 
>> https://support.tidelift.com/hc/en-us/articles/4406309657876-Lifter-agreement
>> .
>>> It appears that Struts has accepted this already.
>>> 
>>> Perusing the agreement, I see talk of payment, license, and trademark.
>>> So let's cover that, and the topic we want to cover, the Apache Way.
>>> 
>>> Let's be welcoming and friendly, and focus more on what they need to
>>> do, rather than on what they must not do
>>> 
>> 
>> Huge +1 to the above. I really feel that Tidelift is onto something here
>> and am very much willing to work with them (even in my personal capacity).
>> 
>> 
>>> Outline:
>>> 
>>> * So you want to pay a contributor?  Great!  If that is something you
>>> wish to do, do so directly with each contributor as this is not a
>>> service the ASF provides.  Just make sure that each contributori is
>>> aware of each of the five points listed on The Apache Way page[1].  In
>>> particular, be aware that each individual contribution will be
>>> evaluated on its merits and require consensus before being accepted.
>>> 
>>> * All code must be licensed only under the Apache Software License,
>>> with no additional conditions.  Should an individual contributor
>>> become a committer, they will be required to sign an ICLA.  You are
>>> welcome to sign a CCLA.
>>> 
>>> * You are welcome to make nominative use of our trademarks.  If you
>>> require anything more, see out Trademark Policy[2].
>>> 
>>> [1] https://www.apache.org/theapacheway/
>>> [2] https://www.apache.org/foundation/marks/
>> 
>> 
>> I'd like to refocus this thread (or perhaps fork a new one) on expanding
>> this useful list started by Sam. I also plan to talk to Tidelift later this
>> week so having as much data points as I possibly can would be super useful.
>> 
>> Anyone has anything else they feel like adding to the above list?
>> 
>> Thanks,
>> Roman.
>> 


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

Re: [apache/comdev-site] [Improved] Added ASF logo as the comdev site logo (#69)

[Dave Fisher]

It’s just three approvals of PRs and not really a contribution. Call them 
random non-binding +1.

Sent from my iPhone

> On Jan 4, 2022, at 7:57 AM, Rodent of Unusual Size  wrote:
> 
> Consider as well the current spotlight on FOSS provenance tracking since
> log4j.  Allowing anonymous contributions/approvals into anything
> 'customer-facing' seems contraindicated.
> 
> -- 
> Ken Coar ()
> Software developer, author, opinionist
> Sanagendamgagwedweinini


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

Re: Proposal to add "release requirements" check

[Dave Fisher]

> On Nov 8, 2021, at 9:48 AM, Jarek Potiuk  wrote:
> 
>> However this does not solve the issue of stale download pages: how do
> you know when a release version is no longer supported?
> 
> What do you mean?
> 
> Is there a requirement for that that I missed? I believe the
> requirement is only about removing artifacts from "downloads.a.o" and
> this is a completely different issue.

There is no definitive rule about the path to the download page. There is no 
standard and with over 200 projects, 35 podlings, and lots of products change 
is difficult.

There is one definite requirement that can be checked. Whether the releases in 
svn are properly formed.

We do this in the Incubator with the Clutch Analysis. 
https://svn.apache.org/repos/asf/incubator/public/trunk/clutch2.py - L1132
Output found by clicking on a podling on https://incubator.apache.org/clutch/

We also have code in ASF Pelican - 
https://github.com/apache/infrastructure-pelican/blob/master/plugins/asfdata.py#L362
That was used to produce this example for Hadoop - 
https://template.staged.apache.org/downloads.html
Using this template - 
https://github.com/apache/template-site/blob/main/content/downloads.ezmd
Control is - https://github.com/apache/template-site/blob/main/asfdata.yaml#L110

To review projects you might find out where their download page is by reviewing 
the project DOAP file, but we’ve never been able to get all projects to 
maintain one.

Maybe it’s time to more carefully define what the ask is here.

> 
> On Mon, Nov 8, 2021 at 6:42 PM sebb  wrote:
>> 
>> On Mon, 8 Nov 2021 at 17:11, Jarek Potiuk  wrote:
>>> 
>>> Yeah. We will have different URLs especially as more artifacts are
>>> produced (airflow has 3 of those each with different download pages).
>>> 
>>> But this should be straightforward when you can add the url when
>>> registering the release (as Sebb proposed). According to the release
>>> process you should register each such "release type" separately and
>>> adding a URL there will do the job nicely. And initially it can be
>>> optional and once we figure out how to communicate it best and maybe
>>> try with some projects first we can make it obligatory at release
>>> registration. We could make it convenient - for example an easy way to
>>> copy a previously added URL from selected previous release or
>>> autocomplete from previous entries - making the process of entry as
>>> smooth (or even smoother) than it is today.
>> 
>> Or you could just ask for the URL if the release is not already on a
>> download page.
>> This would mean parsing the page of course, but could be used to
>> provide immediate feedback if the page is non-conforming.
>> 
>> Asking for the page might also nudge projects to move to generic pages
>> rather than one per release.
>> 
>> However this does not solve the issue of stale download pages: how do
>> you know when a release version is no longer supported?
>> 
>>> J.
>>> 
>>> 
>>> On Mon, Nov 8, 2021 at 4:19 PM sebb  wrote:
 
 On Mon, 8 Nov 2021 at 11:29, Hans Van Akelyen
  wrote:
> 
> Hi,
> 
> I think a certain level of uniformity would not be bad for this.
> Having a fixed path to the downloads for each project makes it simpler for
> the users to "shop" for Apache projects.
> 
> Having .a.o/download/ as a link that should point to the 
> resources
> makes it simpler for everyone.
 
 I agree, but expect a lot of complaints if you try to get this enforced.
 (and there's not much point unless it is enforced).
 
> Kind Regards,
> Hans
> 
> On Mon, 8 Nov 2021 at 12:19, Justin Mclean  
> wrote:
> 
>> Hi,
>> 
>>> However that assumes that you know where to find the download page(s).
>>> It also assumes that projects update their download page(s) to only
>>> show current releases.
>> 
>> It does indeed assume that, and a few other things. Currently policy
>> doesn't specify what the download page URL should be, but once known I
>> would guess it wouldn’t change often.
>> 
>> Kind Regards,
>> Justin
>> 
>> 
>> 
>> -
>> 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: 

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

[Dave Fisher]

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.

Sent from my iPhone

> On Sep 19, 2021, at 1:01 PM, Brian Proffitt  wrote:
> 
> As efforts like the Open Source Security Foundation gain traction in the
> FLOSS ecosystem, the ASF has a unique opportunity to provide guidance to
> its projects on the topic of security best practices. To facilitate an open
> and collaborative process, the group would like to request the
> configuration of a new mailing list, secur...@community.apache.org.
> 
> The new list will enable interested participants and members of the ASF
> share best practices and build a collaborative community around infosec
> that ultimately should create a more security development environment for
> Apache projects.
> 
> If at all possible, I would like to request approval for this new list
> as soon as possible. Mark would like to reference this week in his
> ApacheCon keynote, and due to personal travel, I was a bit negligent in
> getting this request out in a timely manner. This is my fault, and I
> apologize for the rush request.
> 
> Thanks,
> Brian
> 
> -- 
> Brian Proffitt
> Member, Apache Community Development PMC
> Red Hat Open Source Program Office


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

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

[Dave Fisher]

+1 - Once accepted here I would like the IPMC to consider similar process for 
accepting podling proposals.

> On Jul 12, 2021, at 12:42 PM, Craig Russell  wrote:
> 
> 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
> 


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

Re: Please redirect automated GitBox emails to different list

[Dave Fisher]

I have rather hard as a mentor in the Incubator now that all new projects use 
GitHub. Much development discussion is driven away from dev@project mailing 
lists and occurs in issues(if enabled) and PRs.

comdev-site: https://github.com/apache/comdev-site/blob/master/.asf.yaml

notifications:
  commits:  comm...@community.apache.org
  issues:   dev@community.apache.org
  pullrequests: dev@community.apache.org

One - issues have not been enabled so that setting is meaningless to 
comdev-site.

Why add notifications@ when commits@ exists?

.asf.yaml allows:

  # Send new/closed PR notifications to dev@
  pullrequests_status:  d...@foo.apache.org
  # Send individual PR comments/reviews to issues@
  pullrequests_comment: iss...@foo.apache.org

So PRs could be split, but we are already having a split discussion of 
https://github.com/apache/comdev-site/pull/64

Tell me why a split discussion is good for the community?

All The Best,
Dave

> On Jul 6, 2021, at 9:37 AM, Brian Thompson  wrote:
> 
> I don't think asking for a new mailing list for GitHub notifications is
> unreasonable.  In fact, I would go as far to say that having a GitHub
> notifications mailing list makes more sense than having those
> notifications being sent to the "dev" mailing list.  Shouldn't the dev
> mailing list be used for discussion about the development rather than
> individual PRs?  Those discussions can still be had on the other
> mailining list, if so desired.
> 
> -- 
> Best regards,
> 
> Brian T
> B.S. Computer Science 2014 (Truman State University)
>  Minor Stasitics
>  Minor Chemistry
>  Minor Mathematics


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

How can I update the 'Project Lead' field in JIRA?

[Dave Barnes]

We've elected a new PMC chair for the Apache Geode project, but the JIRA 
'Project Lead' field has not been updated to reflect the change.
I'm a PMC member, but can't find a way to edit this field myself. How does one 
go about this?

-
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

[Dave Fisher]

What’s the ask here? Once someone has an Apache id then they can map their ids 
using id.Apache.org? They also need to enable 2FA in GitHub.

While more awkward any committer can use gitbox.com.

Maybe, submitting an ICLA should also be requesting an apacheid?

Regards,
Dave

Sent from my iPhone

> On May 8, 2021, at 7:21 PM, Craig Russell  wrote:
> 
> 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
> 


-
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

[Dave Fisher]

Hi Matthew,

> On Apr 6, 2021, at 11:26 AM, Matthew Sacks  wrote:
> 
> - we can also maybe build on the Badgr project, is that what you would say
> is preferable?
> 
> - so ill out it on the incubator list?

I would start by reading https://incubator.apache.org/cookbook/

Some of the requirements include convincing enough Apache Members or IPMC 
Members to be your Champion and Mentors.

You would also need to have a small community of others who want to work with 
you on this project. By small I mean at least two others.

Then you write a proposal and the IPMC decides.

Alternatively, you could find a PMC that would sponsor your project’s 
Incubation.

Thirdly, find a PMC (including ComDev) that would host the development of the 
badge system.

Best Regards,
Dave

PS. Criticism is going to happen, get used to it, and take your time in 
response.

> What about the infra list? Should I
> mentioned it there?
> 
> 
> On Tue, Apr 6, 2021 at 9:29 AM Rich Bowen  wrote:
> 
>> 
>> 
>> On 4/6/21 11:16 AM, Matthew Sacks wrote:
>>> 1) if rather build my own badge software from scratch for the ASF badge
>>> use specifically.
>>> 
>>> It is indeed a software project, and yes you’ve fully misunderstood as
>>> you mentioned, WADR.
>>> 
>>> Whether or not infra decides to use the software will be based on the
>>> usefulness of the Podling PoC for the new badge technology specifically
>>> for ASF badges. If someone wants to fork and resubmit or take it to
>>> GitHub whatever that’s fine, but the original purpose is for the ASF
>>> badge specifically.
>>> 
>>> Should I cc them or present it on their list separately?
>>> 
>>> New podling, new software, yes.
>>> 
>>> Does this change your -1?
>> 
>> I see. Well, then, I would have to say that this is the wrong place to
>> have this vote, and the wrong place to have this conversation. You need
>> to make a proposal over on the Incubator list. Having a vote on this
>> here will have no consequence, and will not be binding on anything.
>> 
>> That said, reinventing something just so we can have our own is not
>> something I'm a fan of, but if that's interesting to you, I'm certainly
>> not going to say no, either.
>> 
>>> On Tue, Apr 6, 2021 at 8:04 AM Rich Bowen >> <mailto:rbo...@rcbowen.com>> wrote:
>>> 
>>> 
>>> 
>>>On 4/6/21 10:57 AM, Matthew Sacks wrote:
>>>> I’m not sure wtf it doing but this GT relying on the elder
>>>buffers and more
>>>> experienced guidance (specifically Mark Thomas, JimJag’s input,
>> Brett
>>>> Porter) here goes: can we vote yes or no should this be turned
>> into a
>>>> proposal of some kind, incubator or other, depending on where it
>>>is most
>>>> appropriated.
>>>> 
>>>> Calling a vote yes or no to create a formal application for
>>>project hosting
>>>> in the ASF for the PoC.
>>>> 
>>>> PoC success criteria TBD.
>>>> 
>>>> I’ve proposed one podling before, but I’m rusty on this process.
>>>> 
>>>> Ready to dedicate resources to this project.
>>> 
>>>-1 - this is not podling material. Podlings are for software project
>> to
>>>be hosted at the Foundation. This is not a software project. It is
>>>standing up a service with an existing externally-developed software
>>>project - unless I am completely misunderstanding what you're trying
>> to
>>>do here.
>>> 
>>>What I understood from the entire thread is that you wish to run a
>>>badge
>>>service, using Badgr (or other similar existing software project).
>>> 
>>>Have I completely misunderstood your intent?
>>> 
>>>If you do, in fact, intend to start a *new* software project to
>> develop
>>>a badge solution, and make that an Apache project, this is not the
>>>place
>>>to have that conversation. That would be over on the Incubator
>>>mailing list.
>>> 
>>>--
>>>Rich Bowen - rbo...@rcbowen.com <mailto:rbo...@rcbowen.com>
>>>@rbowen
>>> 
>>> --
>>> Thank you, Matthew
>> 
>> --
>> Rich Bowen - rbo...@rcbowen.com
>> @rbowen
>> 
> -- 
> Thank you, Matthew


-
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

[Dave Fisher]

Hi -

I perceived sarcasm from you as well.

I’m personally unsure about the best way to earn Apache merit badges.

I would say that the metrics for badges ought not parallel too much other merit 
measures like committer, PMC, membership, and the rest. If too close then there 
will be questions for PMCs which naturally differ on measurements for 
committers and PMC membership in their community.

Something like emails, commit lines, issues, etcetera.

Just my thoughts.

Regards,
Dave

Sent from my iPhone

> On Apr 5, 2021, at 5:24 PM, Matthew Sacks  wrote:
> 
> If you think there’s snark in my reply, you’ve misinterpreted it as I’m
> dead serious. Instead of letting personal opinions on awards because of
> what sounds like a bad personal experience indicates to me the real
> benefit if the proposal was missed, and why put down an idea that promotes
> pride in one's work?
> 
> That is not the ASF I know.
> The ASF I know is board members personally showing me around when I had a
> very uninteresting project that turned into a podling.
> 
> It helps encourage involvement in contributions to open source, the whole
> point of the badge.
> 
> Also, his assessment was completely based on personal opinion, nothing to
> do with benefit or no benefit to the ASF.
> 
> Putting down good ideas is more damaging to focus soon than me asking for
> real facts when presented with personal convictions.
> 
> Thanks for the etiquette suggestion.
> 
> Regardless of your suggestions, on etiquette, It seems the majority is in
> favor.
> 
> So now we vote?
> 
> 
>> On Mon, Apr 5, 2021 at 4:58 PM Craig Russell  wrote:
>> 
>> 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 jus

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

[Dave Fisher]

> On Mar 8, 2021, at 11:15 AM, Craig Russell  wrote:
> 
> 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.

This is easily done with .asf.yaml

https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories

All The Best,
Dave

> 
> 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> 
>> mailto:dev@community.apache.org>>; Beckerle, Mike 
>> mailto:mbecke...@owlcyberdefense.com>>
>> Cc: Christofer Dutz > <mailto:christofer.d...@c-ware.de>>
>> 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 
>> <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 
>> <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 
>> <mailto:mbecke...@owlcyberdefense.com><mailto:bhum...@owlcyberdefense.com 
>> <mailto:bhum...@owlcyberdefense.com>>
>> 
>> P +1-781-330-0412
>> 
>> Connect with us!
>> 
>> [cid:d9106eb7-9508-484a-bedb-46cca6c7de97 
>> ]<https://www.linkedin.com/company/owlcyberdefense/
>>  
>> <https://www.linkedin.com/company/owlcyberdefense/>>[cid:0a4b8d2b-e338-4c2c-ae52-7beabc7153d8
>>  
>> ]<https://twitter.com/owlcyberdefense
>>  <https://twitter.com/owlcyberdefense>>
>> 
>> [cid:e237fe61-d373-4b2a-ae9e-cc427a8eb4a9 
>> ]<https://owlcyberdefense.com/resources/events/
>>  <https://owlcyberdefense.com/resources/events/>>
>> 
>> 
>> 
>> 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
> 


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

Re: ASF Board Report Wizard - how are change percentages calculated?

[Dave Barnes]

Thanks, Daniel.
Based on my understanding of your explanation, I'll choose to trust the raw
numbers and calculate the percentages based on those numbers.
Do you concur?
BR,
Dave


On Mon, Feb 8, 2021 at 11:51 PM Daniel Gruno  wrote:

> A quarter in this scenario is defined as "the 3 months preceding this
> day", as projects typically report every 3 months on a somewhat
> arbitrary day (3rd wednesday), and some projects are asked to report
> again the following month.
>
> Thus, it's highly likely that the reports were not made _exactly_ 3
> months apart (usually there can be up to a weeks worth of hidden extra
> data due to the 3rd wednesday rule), and therefore differ a bit in the
> numbers that are used.
>
> For instance, one report could be filed on March 10th, and the next on
> June 17th, leaving the time between 10th and 17th to skew the stats.
>
> HTH.
>
> On 08/02/2021 20.27, Dave Barnes wrote:
> > On my project (geode.apache.org), some of this quarter's change
> percentages are way off, if they're comparing to the previous quarter.
> These percentages should be near zero, yes?
> >
> > Today’s   stats:
> > - 322 PRs opened on GitHub, past quarter (-13% decrease)
> > - 321 PRs closed on GitHub, past quarter (-12% decrease)
> >
> > Previous quarter:
> > - 324 PRs opened on GitHub
> > - 325 PRs closed on GitHub
> >
> > Or am I misunderstanding how the percentages are figured?
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>

ASF Board Report Wizard - how are change percentages calculated?

[Dave Barnes]

On my project (geode.apache.org), some of this quarter's change percentages are 
way off, if they're comparing to the previous quarter. These percentages should 
be near zero, yes?

Today’s stats:
- 322 PRs opened on GitHub, past quarter (-13% decrease)
- 321 PRs closed on GitHub, past quarter (-12% decrease)

Previous quarter:
- 324 PRs opened on GitHub
- 325 PRs closed on GitHub

Or am I misunderstanding how the percentages are figured?


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

Re: [GitHub] [comdev-fosdem-static] kennethpaskett opened a new pull request #3: Resize/update the Project Logos to be similar in size.

[Dave Fisher]

Is there a commits mailing list for Comdev? It should be possible to use 
.asf.yaml to send these emails there.

Sent from my iPhone

> On Feb 4, 2021, at 8:08 PM, GitBox  wrote:
> 
> 
> kennethpaskett opened a new pull request #3:
> URL: https://github.com/apache/comdev-fosdem-static/pull/3
> 
> 
> 
> 
> 
> 
> 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.
> 
> 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
> 


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

Re: UX Research Findings Readout for Apache Beam Community

[Dave Fisher]

I see that you sent the same message to u...@beam.apache.org 
<mailto:u...@beam.apache.org> and d...@beam.apache.org 
<mailto:d...@beam.apache.org>.

Thanks for sharing.

Regards,
Dave

> On Jan 28, 2021, at 11:01 AM, Carlos Camacho Frausto 
>  wrote:
> 
> Hello,
> Some weeks ago, our firm conducted a User Experience Research Study
> for Apache Beam to identify users’ needs and pain points when learning and
> using Apache Beam.
> 
> *Today, we are glad to invite you to a Readout session where we will
> present the key findings and a list of recommendations in order to improve
> the learning experience for Apache Beam users. This session will consider a
> Q where you’ll be able to interact with the community. *
> 
> We are considering a session of 60 minutes on any of these possible dates:
> 
>   - Thursday, February 11th at 11:00 AM CST / 6:00 PM CEST
>   - Thursday, February 11th at 2:00 PM CST / 9:00 PM CEST
>   - Friday, February 12th at 11:00 AM CST / 6:00 PM CEST
>   - Friday, February 12th at 2:00 PM CST / 9:00 PM CEST
> 
> 
> If you would like to attend the session, *please help us know which of the
> dates/times options work best for you by filling up this form
> <https://forms.gle/LHjB3uYiJ35BFcbM6>*. <https://forms.gle/LHjB3uYiJ35BFcbM6
>> 
> 
> We appreciate your help, and you can expect more details on the Readout
> soon!
> 
> -- 
> 
> Carlos Camacho | WIZELINE
> 
> UX Designer
> 
> carlos.cama...@wizeline.com
> 
> Amado Nervo 2200, Esfera P6, Col. Jardines del Sol, 45050 Zapopan, Jal.
> 
> Follow us @WizelineGlobal <https://twitter.com/wizelineglobal> | Facebook
> <https://www.facebook.com/WizelineGlobal> | LinkedIn
> <https://www.linkedin.com/company/wizelinee>
> 
> Share feedback on Clutch <https://clutch.co/review/submit/375119>
> 
> -- 
> *This email and its contents (including any attachments) are being sent to
> you on the condition of confidentiality and may be protected by legal
> privilege. Access to this email by anyone other than the intended recipient
> is unauthorized. If you are not the intended recipient, please immediately
> notify the sender by replying to this message and delete the material
> immediately from your system. Any further use, dissemination, distribution
> or reproduction of this email is strictly prohibited. Further, no
> representation is made with respect to any content contained in this email.*

Re: Privacy Policy As it Applies to Apache Open Office

[Dave Fisher]

Hi -

The proper place to ask is d...@openoffice.apache.org 
<mailto:d...@openoffice.apache.org>.

That said I am qualified to answer.

(1) See www.openoffice.org/privacy.html 
<http://www.openoffice.org/privacy.html>. This applies to downloads in the 
sense that there is an access log. We also log some basic information during an 
update check.

(2) If you sign up for the User Forum at forum.openoffice.org 
<http://forum.openoffice.org/> then we have that account information inside 
Apache.

(3) If you purchase a DVD or CD from a third party then we cannot answer about 
the information you might share with them.

(4) Never pay for a download. Always download from www.openoffice.org 
<http://www.openoffice.org/> (redirects to SourceForge)

(5) If you register your user information within the application that is never 
shared with us.

Regards,
Dave


> On Oct 29, 2020, at 9:22 AM, Brian Waltz  wrote:
> 
> Hey Guys,
> 
> I apologize if this is the wrong place to ask. I've tried to search around 
> the site for a bit to find the privacy policy for Apache Open Office. Is 
> there a place where the policy as it applies to the software (not the 
> website) is posted, or does the website privacy policy also apply to the 
> software? Thank you for any information you can provide.
> 
> 
> Brian Waltz | Systems Engineer
> Carson City School District 
> Department of Innovation and Technology
> O: 775.283.2151
> W: carsoncityschools.com <http://carsoncityschools.com/>
> A: 1402 W. King St. Carson City, NV 89703
> 
>  <https://twitter.com/CCSDDoIT>
> 
> 
> 
> 
> * CONFIDENTIALITY NOTICE: This e-mail contains private, 
> privileged and confidential information belonging to the sender. The 
> information herein is solely for the use of the addressee. If your receipt of 
> this transmission has occurred as the result of an error, in such 
> circumstances, you are advised that you may not disclose, copy, distribute or 
> take any other action in reliance on the information transmitted. The Carson 
> City School District does not guarantee that this communication is free of 
> viruses, interceptions or interference, and does not endorse the sender's 
> personal opinions or similar information which may be contained in this 
> message. To report email abuse - ab...@carson.k12.nv.us 
> <mailto:ab...@carson.k12.nv.us> *

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Let’s keep this simple.

Focus on your needs for clarification for Helm Charts.

I really don’t have the time or inclination to parse out what troubles there 
are for OpenOffice in your plan. I already have a long list with unexpected 
issues and mandates.

The Foundation exists for its Project Communities. The Board will need to 
decide if it will mandate any changes to PMCs.

VP, Legal Affairs has been delegated the responsibility for Release Policies.

Mandating changes to volunteers is like pushing a string and herding cats.

I don’t mean to be harsh and do want your effort to be successful. Don’t let 
perfection be your enemy.

Best Regards,
Dave

Sent from my iPhone

> On Oct 16, 2020, at 7:58 AM, Jarek Potiuk  wrote:
> 
> I do not want to make any assumptions on Windows/MacOS etc - for me this is
> really just proposal to clarify the ASF policies which (as far as at
> least I understand) are not up-to-date with some distribution mechanisms
> for convenience packages that have become popular way that our users can
> conveniently use to install our software.
> 
> The OpenOffice came because Joan stepped up and raised the point that
> current proposal is not ok for OOofice so I tried to come up with ideas how
> to make it works also for OOffice. I hope discussing it here at the devcom
> is the right place to do.
> 
> Would you be the right person to comment on the proposal Dave from the Open
> Office team? I see you are on the PMC list of Open Office? Would you be
> happy with the proposal? Or maybe you think it is not needed ?
> 
> Just to clarify my intentions (for the whole proposal):
> 
> I just want to make sure that those who are interested in clarifying the
> policy in the way that will make it easier for PMCs to follow the policies
> and make sure that those convenience packages are prepared accordingly,
> including the indemnification promise that ASF gives to the PMCs.
> According the the PMC gude: http://www.apache.org/dev/pmc.html it's the
> PMCs responsibility to follow the policies:
> 
> COMPLY WITH LEGAL AFFAIRS POLICIES¶
> PMCs SHALL ensure that the work on their project and the code that they
> produce comply with relevant Legal Affairs Committee policies, including
> appropriately using the Apache License, handling IP and copyrights
> correctly, handling cryptography, and producing official software releases
> of their products.
> 
> As a PMC of Apache Airflow I simply find it difficult to follow when it
> comes to helm charts/docker images, that's why I came forward with the
> proposal how to modify those policies to adapt to those distribution
> mechanisms - and my intention is to address any concerns other PMC might
> have here. I hope we can collaborate on that.
> 
> J.
> 
> 
>> On Fri, Oct 16, 2020 at 3:05 PM Dave Fisher  wrote:
>> 
>> Questions related to OpenOffice must be discussed with the OpenOffice PMC.
>> Joan is an observer and I don’t recall her asking the PMC.
>> 
>> Please don’t make any assumptions about builds for Windows, macOS (we
>> support 10.7 and newer) and Linux. Community members on their own build
>> OS/2 and FreeBSD versions.
>> 
>> OpenOffice is completely volunteer driven.
>> 
>> Many in the community are not native English speakers.
>> 
>> Tread carefully.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>>> On Oct 16, 2020, at 2:46 AM, Jarek Potiuk  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> As Apache Airflow 2.0 alpha is out, I have some time to come back to the
>>> discussion. I also add Joan who was discussing the policy in a
>>> separate thread in the builds@ devlist:
>>> 
>> https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E
>>> 
>>> Joan - I hope you are back and we can continue the discussion. I'd love
>> to
>>> come up with the proposal that will include the specifics of OOffice
>>> releases. The proposal is here -
>>> 
>> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages
>> .
>>> Happy to hear some responses on my comments/proposal
>>> Also anyone who is interested - I invite you to comment on the proposal.
>>> 
>>> My plan is to - possibly - come up with a proposal that we all people
>> here
>>> will be ok with (hopefully next week) and submit it to the legal team of
>>> ASF for review/opinions.
>>> 
>>> J.
>>> 
>>> 
>>>> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:
>>>> 
>>>> Cool. Thanks Ber

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Questions related to OpenOffice must be discussed with the OpenOffice PMC. Joan 
is an observer and I don’t recall her asking the PMC.

Please don’t make any assumptions about builds for Windows, macOS (we support 
10.7 and newer) and Linux. Community members on their own build OS/2 and 
FreeBSD versions.

OpenOffice is completely volunteer driven. 

Many in the community are not native English speakers.

Tread carefully.

Regards,
Dave

Sent from my iPhone

> On Oct 16, 2020, at 2:46 AM, Jarek Potiuk  wrote:
> 
> Hello everyone,
> 
> As Apache Airflow 2.0 alpha is out, I have some time to come back to the
> discussion. I also add Joan who was discussing the policy in a
> separate thread in the builds@ devlist:
> https://lists.apache.org/thread.html/r18e21d4719755f83fc67a81c842f7a59a7aa76cd1f621b1362cdd6ae%40%3Cbuilds.apache.org%3E
> 
> Joan - I hope you are back and we can continue the discussion. I'd love to
> come up with the proposal that will include the specifics of OOffice
> releases. The proposal is here -
> https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages.
> Happy to hear some responses on my comments/proposal
> Also anyone who is interested - I invite you to comment on the proposal.
> 
> My plan is to - possibly - come up with a proposal that we all people here
> will be ok with (hopefully next week) and submit it to the legal team of
> ASF for review/opinions.
> 
> J.
> 
> 
>> On Tue, Sep 15, 2020 at 2:06 PM Jarek Potiuk  wrote:
>> 
>> Cool. Thanks Bertrand - I am aware of some of those, but this list will be
>> helpful so I can make some of the references to those in my proposal (and I
>> encourage everyone else to do so). I am super-happy to merge yours with
>> mine. I believe the "spirit" of those is rather similar. I am fully aware
>> legal review should be done - I want now to get some initial feedback and
>> see what controversies the proposal raises and polish it a bit, but I 100%
>> understand the policies are binding for the ASF and the risk and legal side
>> of it should be very carefully considered.
>> 
>> Note - I just run through a few of the comments we have there and just for
>> the sake of keeping people informed on what has changed so far here are
>> some "gists" of my changes comparing to the first draft:
>> 
>> * there is an open question about the viability of putting all the
>> instructions or scripts to build the binary dependencies into  released
>> sources. Giving the example of OpenOffice, CouchDB and Erlang which makes
>> it next to impossible to do. So I proposed to explicitly say that any form
>> of the instructions: scripts, manual instruction or POINTERS to the right
>> instructions is fine. Simple HTTP link where you can find how to build an
>> external OSS library should be perfectly fine. My ultimate goal is that
>> whatever whenever the source .tar.gz package is created - the goal is that
>> the user can get the sources and following the instructions (including the
>> links to instructions) can - potentially rebuild the software legally. It
>> might be a complex and recursive process (build a library to build a
>> library) and at times those instructions might not work (as it is with all
>> the instructions) but at least an attempt should be made to make it
>> possible.
>> 
>> * The "official" 3rd-party binary package is not a good name - I replaced
>> it for now with the "maintained OSS" binary package. The idea behind it is
>> that shortly - it should be open-source and it should be maintained. So
>> while the name does not reflect all the subtleties of "maintained" and
>> "OSS" but it reflects the spirit. I tried to make the "recursive"
>> definition as much relaxed as possible (in terms of SHOULD vs. MUST except
>> with the Licencing which is a MUST)
>> 
>> * In pretty much all cases where I write about "best practices", they are
>> not absolute requirements - so whenever possible they are SHOULD instead of
>> MUST. I am very far from imposing all the best practices on all ASF
>> projects - that will be impractical and stupid thing to do. I really treat
>> those "best practices" as "beacons" - targets that we can have in mind but
>> might never fully achieve them. And as long as we have good reason, not to
>> follow those practices - by all means we do not have to. But if easy and
>> possible, I see the best practices as a powerful message that improves the
>> "Brand" of ASF in general from the user perspective. There are no "bonus
>>

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Every release must be made in SVN on dist.apache.org. All other channels are 
optional and may or may not have Infra support.

I view this as a request to have ComDev or Infra manage a Gitbox/Github 
repository where any PMC can publish a PMC approved Helm Chart release from 
their project.

How to make a Helm Chart compliant with Apache Release Policy would part of the 
documentation.

Sent from my iPhone

> On Sep 5, 2020, at 3:30 PM, Kaxil Naik  wrote:
> 
> 
>> 
>> The point is that we MUST give the users possibility to (re)build those
> images on their own if they want. We
> 
> 
> From http://www.apache.org/legal/release-policy.html#source-packages, it
> does not say it has to be on PyPI. I will reiterate what I said in the
> Github issue, having a binary on PyPI is no guarantee that it will stay
> there. Having a binary on Github releases
> https://github.com/jbub/pgbouncer_exporter/tags also does not guarantee it
> would not change. If the license are correct and the source is available I
> definitely do not see this as a problem:
> 
> Every ASF release MUST contain one or more source packages, which MUST be
>> sufficient for a user to build and test the release provided they have
>> access to the appropriate platform and tools.
> 
> 
> 
>> On Sat, Sep 5, 2020 at 10:33 PM Jarek Potiuk  wrote:
>> 
>> @Matt Sicker  -> agree on both, central chart repo, and
>> per-project sources for charts. Though packaging is a bit different than
>> Docker though. The packages contain tar.gz sources of the chart (which
>> usually includes quite complex go templating logic, not just simple yaml
>> files)  and those templates include names of the images used. This makes
>> the Helm chart much more close to the -src.tar.gz files we release now than
>> to Docker Images we publish. So IMHO the .tgz part should follow the normal
>> release process with voting @Kaxilnaik .
>> Unless those are the very same sources of product that are already formally
>> released. But then @Gaetan Semet previously pointed out as bad practice
>> to bind the two together.
>> IMHO that means that we have to vote on each Chart release. But I'd love
>> what others think - knowing this packaging details.
>> 
>> @ermanndimb- my point for images pointed to by the helm chart is not about
>> copying full sources (I think from this discussion I realised where the
>> main confusion was) . This is not needed. I just made a PR to show how this
>> can be done with the pgbouncer-exporter.  This is quite a good example to
>> base our discussion on: https://github.com/apache/airflow/pull/10759
>> 
>> The point is that we MUST give the users possibility to (re)build those
>> images on their own if they want. They should be able to do that using:
>> 
>>  a) official base images (DockerHub has the "official image program" for
>> platforms. openjdk, python,debian, alpine - those are all official images
>> in DockerHub terms
>>  b) having access to properly licensed source code with some guarantees
>> that it will not disappear ("official" repo, multiple forks in Github,
>> heavily used by others, fork under "apache" organisation) .
>>  c) instructions where to find the sources and build the images
>> (Dockerfile + necessary scripts to build the image if in case it is not
>> straightforward). Similarly as we provide instructions on building the
>> "product".
>> 
>> If the first two are available but it's not obvious how the image was built
>> - IMHO we need to provide the user instructions on how to build those
>> images (ideally a script that does it automatically).
>> 
>> This is all fulfilled by the PR above as an example:
>> a) based on official, alpine image
>> b) the pgbouncer code is properly licenced and we forked the sources
>> several times to be sure it won't disappear
>> c) we have a script that builds and publishes the image (image is published
>> under apache/airflow DockerHub)
>> 
>> IMHO - that's a very good example to show the kind of approach we can take,
>> and shows that it isn't difficult to handle it well at all.
>> 
>> The alternative that I am afraid of is - that we require our users to use
>> binaries which are not "official" but maintained and controlled by
>> 3rd-party (without a straightforward way of building the binary from
>> official images + properly licensed sources + instructions). If we do not
>> give those to the user but we simply point to a 3rd-party binary bimage -
>> we both endorse the 3rd party, and introduce dependency on the 3rd-party.
>> The user then has to rely on the 3rd-party to use the Airflow Helm Chart -
>> which I think is a very bad idea.
>> 
>> J.
>> 
>> 
>>> On Sat, Sep 5, 2020 at 7:42 PM Kaxil Naik  wrote:
>>> 
>>> Does voting needs to happen for "releasing" the Helm chart ? Do we any
>>> guidelines from the ASF around releasing Helm Chart & Dockerfile?
>>> 
 On Sat, Sep 5, 2020, 17:36 Matt Sicker  wrote:
>>> 
 If packaging is similar to Docker, then our Helm charts will still
 need some third 

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

The ASF and the Apache Way is all about the community around an open source 
software project. If there is no community around this deprecated package then 
you will need to contact each Apache community that might be interested and ask 
them directly.

If you have a group of developers who want to preserve this project then 
incubating an Apache project could be an approach.

Regards,
Dave

Sent from my iPhone

> On Sep 3, 2020, at 7:00 PM, Ween Jiann  wrote:
> 
> Hi Dave,
> 
> Just to clarify, my suggestion is to move only charts related to ASF projects 
> to the apache git repo.
> These charts have been deprecated as part of the repo deprecation, they have 
> no choice but to move somewhere or be archived.
> 
> If this gains some traction, I'll create an issue and contact the maintainers 
> of the charts.
> 
>> On 2020/09/03 21:01:12, Dave Fisher  wrote: 
>> Hi -
>> 
>> Does the Helm Chart community wish to explore becoming an Apache Project 
>> Community?
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>>> On Sep 3, 2020, at 12:33 PM, Ween Jiann  wrote:
>>> 
>>> Hi all,
>>> 
>>> The helm team has deprecated the charts repository and will be archiving it 
>>> in Nov. Here’s the link to the notice 
>>> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>>> 
>>> It looks like that are quite a few charts for ASF projects such as Airflow, 
>>> Hadoop, Spark, Solr (not exhaustive) that have yet to be adopted by anyone. 
>>> It would make sense to re-home them into a single git in for example 
>>> apache/charts. This would facilitate easier distribution of various ASF 
>>> projects via a single helm repo, and setting up tests and CI integration 
>>> needs only to be done once.
>>> 
>>> Cheers,
>>> WJ
>>> 
>>> -
>>> 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

Re: Migration and consolidation helm charts for ASF projects from helm/charts to apache/charts git

[Dave Fisher]

Hi -

Does the Helm Chart community wish to explore becoming an Apache Project 
Community?

Regards,
Dave

Sent from my iPhone

> On Sep 3, 2020, at 12:33 PM, Ween Jiann  wrote:
> 
> Hi all,
> 
> The helm team has deprecated the charts repository and will be archiving it 
> in Nov. Here’s the link to the notice 
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
> 
> It looks like that are quite a few charts for ASF projects such as Airflow, 
> Hadoop, Spark, Solr (not exhaustive) that have yet to be adopted by anyone. 
> It would make sense to re-home them into a single git in for example 
> apache/charts. This would facilitate easier distribution of various ASF 
> projects via a single helm repo, and setting up tests and CI integration 
> needs only to be done once.
> 
> Cheers,
> WJ
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: ASF events: inquiry on requirements for speakers

[Dave Fisher]

Hi Elena,

You wrote your two emails to a public mailing list. You did get a response to 
your first email. You can see that response in our public archives here: 
https://lists.apache.org/thread.html/ra646b0124610d3178102c085ad02a0f1be1572ca1a0b8b1c036f2b38%40%3Cdev.community.apache.org%3E

Regards,
Dave

> On Aug 28, 2020, at 9:52 AM, Elena Sporrer  
> wrote:
> 
> Hi Team, 
>  
> Could you please help me to find the right contact person to get more info on 
> upcoming events and requirements for ASF events?
> Would appreciate your tips! 
>  
> Thanks and best regards, 
>  
>  
>  <http://datagrate.com/>  
> Elena​
>  
> Sporrer
> Engagement & Delivery Manager 
> at 
> datagrate
> C +1 (813) 970-7265 
> Tampa, FL
> Essential Enteprise Application Integration Solutions · Proud Partner since 
> 2012
>  <http://talend.com/>
> From: Elena Sporrer  <mailto:elena.spor...@datagrate.com>>
> Date: Thursday, August 20, 2020 at 16:22
> To: "dev@community.apache.org <mailto:dev@community.apache.org>" 
> mailto:dev@community.apache.org>>
> Subject: ASF events: inquiry on requirements for speakers
>  
> Dear Apache Development Community Team, 
>  
> I’ve checked your online resources and helpful tips with regards to upcoming 
> ASF events.
> However, there are still a few questions which would be really helpful in 
> order for us to prepare for listing us as potential speakers:
>  
> What are you looking for when deciding on the speakers?
> Where can I find a full list of requirements for topics submission, format, 
> etc.?
> What is the timeline cycle for a speaker from the moment of applying to 
> getting approved, presenting, etc.?
> Who do we submit our proposal to?
>  
> Is there anyone who I could perhaps call to get a bit more details?
> Thanks and I would highly appreciate your response! 
>  
> Thanks and best regards, 
> Elena 
>  
>  
>  <http://datagrate.com/>  
> Elena​
>  
> Sporrer
> Engagement & Delivery Manager 
> at 
> datagrate
> C +1 (813) 970-7265 
> Tampa, FL
> Essential Enteprise Application Integration Solutions · Proud Partner since 
> 2012
>  <http://talend.com/>

Re: Triage role on Github

[Dave Fisher]

> On Aug 20, 2020, at 12:48 PM, Jacques Le Roux  
> wrote:
> 
> Le 20/08/2020 à 15:08, Bertrand Delacretaz a écrit :
>> On Thu, Aug 20, 2020 at 3:01 PM Harbs  wrote:
>>> I also don’t see any harm in making triage rights open to all
>> I suspect creative minds might find a way to spam us with this if it's
>> "open to all" ?
> 
> From my experience it always ends like this...
> 
> 
>> 
>> For our wikis I think we generally give write access to anyone who
>> *asks on our mailing lists* and has some connection to our projects.
>> If that's what people mean by "open to all" I'm fine.
> 
> Agreed

IMO - It’s important for the triage activity to generate some type of 
notification email so that it is possible for the PMC to triage the triage.

Regards,
Dave

> 
> Jacques
> 
>> 
>> I suppose the .asf.yaml mechanism could be extended to list GitHub
>> users who have this role?
>> 
>> -Bertrand
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Problem running build.sh

[Dave Fisher]

Hi Bud,

You should reach out to the Apache Ant project at d...@ant.apache.org

Regards,
Dave

Sent from my iPhone

> On May 18, 2020, at 9:02 AM, Bud Rozwood  wrote:
> 
> Sorry, the error is when I run "bootstrap/bin/ant -f fetch.xml 
> -Ddest=optional".
> 
>> On 2020/05/18 15:53:54, Bud Rozwood  wrote: 
>> Hi,
>> 
>> I'm trying to install apache-ant-1.10.8 from source but I keep running into 
>> this issue:
>> 
>> -fetch-netrexx:
>> 
>> -fetch-netrexx-no-commons-net:
>>  [get] Getting: 
>> ftp://ftp.software.ibm.com/software/awdtools/netrexx/NetRexx.zip
>>  [get] To: /home/user/.ant/tempcache/NetRexx.zip
>>  [get] Error getting 
>> ftp://ftp.software.ibm.com/software/awdtools/netrexx/NetRexx.zip to 
>> /home/bud/.ant/tempcache/NetRexx.zip
>> 
>> BUILD FAILED
>> 
>> To test this, I tried downloading it manually via firefox and it says:
>> 
>> "Unable to connect
>> 
>> Firefox can’t establish a connection to the server at ftp.software.ibm.com."
>> 
>> Is there something wrong with the server?
>> 
>> --Bud
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

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

[Dave Fisher]

IIRC the reporter has its own manual cache. You’ll need to wait for Daniel G.

That said the reporter is a convenience. You can submit reports through whimsy 
or directly in svn. Many will help you. Just ask.

Regards,
Dave

Sent from my iPhone

> On Apr 22, 2020, at 7:34 PM, "zhangli...@apache.org"  
> wrote:
> 
> I can see Apache ShardingSphere in all project, but still no permission to
> edit it.
> But I can edit Apache Dubbo, I think it is incorrect, because I am not VP
> of Apache Dubbo.
> 
> --
> 
> Liang Zhang (John)
> Apache ShardingSphere & Dubbo
> 
> 
> Craig Russell  于2020年4月23日周四 上午2:55写道：
> 
>> 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
>> 
>> 


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

Re: Data inconsistency in projects.apache.org

[Dave Fisher]

metadata for project releases is discoverable from the dist in svn. It is 
already done for podlings in the Incubator in the clutch analysis.

It is python. I can provide some help late next week.

Sent from my iPhone

> On Mar 27, 2020, at 1:20 PM, sebb  wrote:
> 
> On Fri, 27 Mar 2020 at 20:01, Hervé BOUTEMY  wrote:
>> 
>> Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit :
 On 3/27/20 3:07 PM, Hervé BOUTEMY wrote:
> It's good to see some interest back on DOAP files content ad organisation,
> now that the projects.apache.org rendering makes them really useful: a
> few years ago, trying to open any discussion on that was deemed to
> failure. But any change is hard, since every PMC will have to be
> involved.
>>> 
>>> What if we - and I'm perfectly prepared to be told "You can't do that
>>> because ..." - fetched remote (ie, project-hosted) doap files, a few at
>>> a time, and move them to the central repo, and as we do that, we go talk
>>> to projects individually, telling them that we're doing it, and why, and
>>> what the new process is for updating. Yes, I'm volunteering to do that
>>> outreach.
>> you can, but I don't see the benefit of this hard work
>> 
>>> 
>>> That way, over time, we'd eventually have all of those files in one
>>> place, making them easier to find and update.
>> find = 2 files (1 for committees, 1 for projects)
> 
> May be more than one for projects.
> e.g. Commons.
> 
>>> 
>>> I'm leaving the file format question for someone else entirely. I am far
>>> less concerned about that, than about ensuring that the files are easily
>>> found and updated.
>> my point about "PMC RDF files" vs "projects DOAP files" is not a question of 
>> format, but a question of amount of data and who would have real knowledge 
>> to update content:
>> - PMC RDF files are very light, rarely updated, and contain data that are 
>> really foundation-centric
>> - projects DOAP files contain a lot more data, can/should be often updated, 
>> with data that are really to be delegated to PMCs given they are more 
>> technical details on code
>> 
>> That's why I really think keeping centralised PMC RDF files and 
>> decentralised projects DOAP files is a good idea.
>> 
>> IMHO, centralising project DOAP files would be a hard task with low benefit, 
>> and even counter productive effect on having every PMC responsible for the 
>> content, that is technical.
>> 
>> On letting PMC RDF files go outside the centralised approach, I'd be curious 
>> to check if the 4 PMCs that chose to host outside of projects.a.o did that 
>> to fill more data, or if they just felt that they'd host this file the same 
>> way they did with project DOAP file.
> 
> I suggest dropping them entirely.
> 
>> Regards,
>> 
>> Hervé
>> 
>>> 
>>> --Rich
>> 
>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Board reporter tool

[Dave Fisher]

Hi Gian,

I think that this because you are a new PMC and the reporter may not be 
updating its project lists. (Whimsy is good.)

If you are still having trouble tomorrow please reach out to board@

Regards,
Dave

Sent from my iPhone

> On Jan 8, 2020, at 6:02 PM, Gian Merlino  wrote:
> 
> Hey Community folks,
> 
> I am currently preparing the board report for Druid, and was trying to use
> the https://reporter.apache.org/wizard/ tool I have heard so much about.
> Unfortunately, it says "It doesn't look like you are on any PMCs". I've
> authenticated as "gian" and I am on the Druid PMC per people.a.o and
> whimsy.a.o. Any idea what's going on?
> 
> Gian


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

Re: Reporter Tool and Releases

[Dave Fisher]

Hi -

Sent from my iPhone

> On Dec 30, 2019, at 12:08 PM, Daniel Gruno  wrote:
> 
> On 26/12/2019 19.52, Dave Fisher wrote:
>> Hi Daniel,
>> Several projects did not report their recent releases in the last Board 
>> cycle. It would be good if the reporter tool would make it easier to provide 
>> the information.
> 
> It is readily available in the tool, on the right hand side in the 'project 
> activity' paragraph. As written elsewhere, the tool does not and cannot write 
> every single paragraph in a report, that is the responsibility of the chair 
> and follows the writing style of said chair.
> 
> I have no plans myself (since I was mentioned by name), at present, to change 
> this behavior.

Understood.

Thank you,
Dave

>> Regards,
>> Dave
>> -
>> 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

Reporter Tool and Releases

[Dave Fisher]

Hi Daniel,

Several projects did not report their recent releases in the last Board cycle. 
It would be good if the reporter tool would make it easier to provide the 
information.

Regards,
Dave
-
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

[Dave Fisher]

Hi -

I’ve tracking only loosely this effort. I am very happy to see Swapnil’s effort 
and I can see this concept to be very helpful for real face to face community 
growth. That is really important as people are connected in the real world!

> On Dec 12, 2019, at 9:18 PM, Alex Harui  wrote:
> 
> I've only been partially following, and I hear and respect the desire for 
> "quality control", but IMO, people talk about Apache all of the time in other 
> events.  For example, when Flex joined the incubator in January 2012, there 
> was a Flex user conference shortly after in April 2012.  I spoke there about 
> the transition from Adobe to Apache and laid out what I knew about Apache at 
> the time.  I posted slides beforehand, but I'm not sure our Mentors looked 
> them over carefully.  We were a podling, so no official PMC members and no 
> Mentors were in attendance.  IIRC, I also practiced this presentation at a 
> small Meetup before the conference.  I'll bet this happens at lots of 
> conferences for podlings.  I included a disclaimer that I wasn't speaking on 
> behalf of Apache, just passing on what I've learned so far.

Two points.

(1) A Disclaimer is a good idea as is using existing material wherever it is 
found on Apache sites and projects.

(2) I was a Flex Mentor. It was my first podling. I was a “junior mentor” and 
not yet a Member. I don’t recall the meeting being a big deal in any way for 
the mentors.

> 
> Hence, my gentle suggestions that disclaiming is better than too much 
> oversight on these community meetings, otherwise ALC is going to be under a 
> heavier burden than other community outreach.  If that's because you want to 
> make ALC the official way to learn about Apache, roughly as formal as the 
> Incubator, ok, then fine, but that might cause other volunteers to shy away 
> or find a path of less overhead by skipping the ALC title and buying a case 
> of beer instead.

I think ALC is important. It can help with cross pollination between projects. 
It can help people find projects and projects find people.

Again I haven’t looked, but to me the most important aspect should be 
disclosing scheduling and projects involved followed by some information about 
attendance.

I think of an ALC as a meetup of meetups.

Also, is the plan for Comdev to manage the ALCs, conferences, or a new 
committee? Or. Is this a combination?

Regards,
Dave

> 
> My 2 cents,
> -Alex
> 
> On 12/12/19, 2:10 PM, "Craig Russell"  wrote:
> 
>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,
>> https://nam04.safelinks.protection.outlook.com/?url=www.apache.orgdata=02%7C01%7Caharui%40adobe.com%7C3ac2d86ccbf54019b11c08d77f500aba%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637117854065911699sdata=NQimXPkKRHJo%2FpQ9yYjcnqVPJuVHumRLi6GYPVyQICE%3Dreserved=0
>> 
>>> 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, thi

Re: Project logo for RedBubble

[Dave Fisher]

Hi -

Project logos are the responsibility of each project. These red bubble requests 
are handled through this community development project.

Regards,


Sent from my iPhone

> On Aug 25, 2019, at 11:03 AM, Craig Crissman 
>  wrote:
> 
> Hello 
> I will be happy to do so but being new to this can you give me a contact who 
> I may speak to prior to doing so.
> 
> 
> Thank You
> Craig Crissman 
> Shenandoah Supervac LLC
> 1-540-968-3174
> 
>> On Aug 20, 2019, at 11:08 PM, Andrew Garza  wrote:
>> 
>> What are u asking for? If i approve of the logo.
>> 
>> On Tue, Aug 20, 2019, 10:43 AM Matthias Seidel 
>> wrote:
>> 
>>> Hi,
>>> 
>>> The Apache OpenOffice project would like to have its logo added to
>>> RedBubble.
>>> 
>>> It is best used with white background color.
>>> 
>>> Kind regards,
>>> 
>>>  Matthias Seidel (on behalf of the Apache OpenOffice PMC)
>>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Focused effort on Apache Way education

[Dave Fisher]

> On Jul 17, 2019, at 10:12 AM, Jim Jagielski  wrote:
> 
> 
> 
>> On Jul 17, 2019, at 12:41 PM, Kenneth Knowles  wrote:
>> 
>> On Wed, Jul 17, 2019 at 9:20 AM Joan Touzet > <mailto:woh...@apache.org>> wrote:
>> 
>>> Hey y'all,
>>> 
>>> On 2019-07-17 7:53, Jim Jagielski wrote:
>>>>> On Jul 17, 2019, at 2:56 AM, Bertrand Delacretaz <
>>> bdelacre...@apache.org> wrote:
>>>>> 
>>>>> On Wed, Jul 17, 2019 at 1:11 AM Dave Fisher 
>>> wrote:
>>>>>> ...I’d like to see the Apache Way described like Euclidean Geometry
>>>>> 
>>>>> I have no clue what this would look like but I'd love to see a blog
>>>>> post of yours describing that vision.
>>>>> 
>>>> +1
>>> 
>>> This was where I was aiming with my original post on board@ (which many
>>> of you may not be able to see).
>>> 
>>> I mentioned I often refer to Shane's summary because it's simple,
>>> concise, and includes the why as well as the what. But I'm aware that
>>> it's just one viewpoint - the website makes that perfectly clear, too.
>>> 
>>> It's been said to me that a lot of The Apache Way can't be written down,
>>> and I would like to challenge that assertion. I'd also like the people
>>> who claim to know the Way best to work as hard as possible on that, too.
>>> 
>> 
>> We need all those voices of how people interpret The Apache Way. And as
>>> Dave hints, we can triangulate its essence with more and more
>>> descriptions. I think it'd be premature to try for that triangulation
>>> without interested parties working on capturing it for themselves first,
>>> revised for a 2019 perspective.
>>> 
>> 
>> Exactly. Sometimes when it is said it cannot be written down, it can mean
>> that it cannot be written down simply and declaratively. Or that it cannot
>> be expressed by being written just once or one way or by one or a few
>> people. The concepts in a novel, an ethnography, or a biography, or even
>> short parables, for example, cannot be simply extracted and written as
>> declarations. The practices of a culture cannot be described fully either,
>> nor transmitted by reading. It may be that the large corpus of writing and
>> slideshows and talking about The Apache Way is a great way to, in fact,
>> write it down. And IMO in such a situation it is important to keep writing
>> about it, and have new people keep writing their take, and to share stories
>> about it. Etc. And of course, it should be expected to constantly change.
>> 
>> Kenn
>> 
> 
> That is why Sally and I have pushed for Apache Way training similar to what 
> Sally does with her media training... open discussion, time for Q, that 
> sort of thing. Sure, writing it down and having it documented is useful, but 
> that isn't a complete solution, nor does it solve the problem completely.

A page at way.apache.org would be good. Here’s is what I had in mind when I 
mentioned Euclidean Geometry. All of it follows from five postulates which are 
statements.

Jim - since you are a Founder I am asking you:

What are the postulates to the Apache Way as simple statements with the 
elegance of Euclid? 

Regards,
Dave



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

Re: Focused effort on Apache Way education

[Dave Fisher]

Inline-

Sent from my iPhone

On Jul 16, 2019, at 2:43 PM, Dmitriy Pavlov  wrote:

>> For the purposes of *THIS* discussion, I think that that's a bit of a
> sidetrack.
> Sure.
> 
> Jim,
> Despite the fact that I do not fully understand the problem, I am ready to
> volunteer to prepare materials. I don't care if it will be a part of Apache
> Training or Apache Com.Dev or slightly another thing.  I just like this
> topic, which why a year ago I've started asking about it here.
> 
> I know about the excellent slides done by Shane
> http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#2
> 
> I also like the idea of explaining not only principles but all principles'
> impact. Ideal material for education would explain why ASF can't drop each
> component of the Apache Way.

I’d like to see the Apache Way described like Euclidean Geometry.

What are the postulates? What are the theorems built from these?

Regards,
Dave
> 
> Sincerely,
> Dmitriy Pavlov
> 
> 
> вт, 16 июл. 2019 г. в 22:46, Rich Bowen :
> 
>> 
>> 
>>> On 7/16/19 2:29 PM, Dmitriy Pavlov wrote:
>>> Hi Jim,
>>> 
>>> Could you mention events you're referring to?
>> 
>> For the purposes of *THIS* discussion, I think that that's a bit of a
>> sidetrack.
>> 
>> Suffice it to say that clearer understanding of the *WHY* around the
>> principles of the Apache Way is necessary, in order that the *WHAT*
>> doesn't get perceived as meaningless, arbitrary, or dispensible.
>> 
>> 
>>> 
>>> In Apache Training (incubating) Justin started to develop content related
>>> to the Incubator
>>> 
>> https://github.com/apache/incubator-training/tree/master/content/ApacheWay
>> ,
>>> so we can consider developing a standalone session related to the Apache
>>> Way principles. But to understand if training will be helpful I would
>> like
>>> to know the entire story.
>>> 
>>> You can share it with me directly if you want.
>>> 
>>> Sincerely
>>> Dmitriy Pavlov
>>> 
>>> вт, 16 июл. 2019 г. в 20:52, Jim Jagielski :
>>> 
>>>> I think that the events of the last several months have clearly shown a
>>>> lack of awareness, knowledge and (and some level) appreciation
>> (adherence)
>>>> to The Apache Way. It would be useful, I think, if this was a focused
>>>> effort w/i the foundation.
>>>> 
>>>> Of course, there is a lot of overlap between ComDev and this effort, and
>>>> so the questions are how best to address this. Maybe some sort of
>> sub-cmmt
>>>> under ComDev? Or spinning this out ala D (but as a PMC to avoid the
>>>> problems that cmmt encountered and to engender trust and
>> collaboration)? Or
>>>> basically focus on it w/i ComDev with the structure "as is"... I think
>>>> having one person "tasked" with herding the cats and coordinating the
>>>> effort would be useful (and I volunteer to do so), no matter what
>> structure
>>>> we decide.
>>>> 
>>>> Thoughts? Ideas?
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>>> For additional commands, e-mail: dev-h...@community.apache.org
>>>> 
>>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 


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

Re: New Project?

[Dave Fisher]

Hi -

To me you have two parts. One fits Apache and the other would need to be 
outside.

(1) Open Source Software which is the library, service and CLI tools. This is 
something that an Apache Community could grow around and be governed in the 
Apache Way. This part can be incubated.

(2) Open Data. Justin refers to Kibble and Pony Mail which are incubating 
projects around consuming Apache Community data mostly. I would point out that 
you could host the data portion of your community elsewhere by some community 
members or others outside of Apache PMCs. Here is a real example. Apache Tika, 
PDFBox and POI PMCs all share a set of regression test documents 
(https://openpreservation.org/blog/2016/10/04/apache-tikas-regression-corpus-tika-1302/)
 and a community member Dominik Stadler 
(https://github.com/centic9/CommonCrawlDocumentDownload) that are retrieved 
from Common Crawl (http://commoncrawl.org) which uses the AWS Public Dataset 
Program (https://aws.amazon.com/opendata/public-datasets/)

Regards,
Dave

> On Jul 2, 2019, at 1:59 PM, Alejandro Caceres  
> wrote:
> 
> Hi Matt,
> 
> Thanks for the response. You are sort of correct, I would say the end goal
> is a service - an open source engine that is able to grab and ingest this
> highly unstructured security information and turn it into something useful
> - then provide that back to the user in a few different forms. One would be
> a web services API for general use exposed to the Internet (a service, like
> you said), and another would be a series of command line tools and
> libraries that others can use to ingest this information easily. the third
> goal would be: not only is the code open source, but all data used in the
> application is available itself, so this could easily be used to run a
> personal node of this information for an organization, scylla.sh is simply
> my instance that I expose to the Internet at large for those that don't
> want to run a "full node". If that is more palatable to the ASF I'm glad to
> make that the focus. In other words: I'm not married to any model here.
> 
> I knew coming in that it's a bit unconventional for Apache, but, I think,
> it is a unique and powerful project that would increase engagement from the
> infosec community in which I personally, as well as my R company have
> some good visibility from. In other words, just testing the waters to see
> how this is received by ASF :).
> 
> Alex
> 
> 
> On Tue, Jul 2, 2019 at 3:44 PM Matt Sicker  wrote:
> 
>> I'm a little unclear about the scope of the project here. This project
>> looks more like a service, and I don't know of any ASF projects that
>> exist to provide services outside the ASF.
>> 
>> On Tue, 2 Jul 2019 at 14:28, Alejandro Caceres
>>  wrote:
>>> 
>>> Hey Folks,
>>> 
>>> I'm interested in submitting a project as a seedling and am looking
>> exactly
>>> where to start. The project is already off the ground, being used by
>> many,
>>> is stable, reasonably mature (it's in alpha release), open source, and
>>> already Apache licensed. I've been looking at a lot of resources to how
>>> best to submit this to Apache and from what I understand I need to:
>>> 
>>> Find a "champion/mentor" for the project and a "sponsor" -> submit an
>>> incubator application -> wait (or do i submit for a vote on general@?)
>> ->
>>> ... -> profit :)
>>> 
>>> For a bit more context, my project is http://scylla.sh or
>>> https://github.com/acaceres2176/scylla. This project aggregates and
>> makes
>>> searchable database leaks and other information security data that is
>> easy
>>> for attackers to find (they have blackhat and underground resources) but
>>> difficult for security professionals trying to defend their network (they
>>> cannot buy stolen data, are not plugged into the blackhat hacker
>> community,
>>> and frankly generally don't know "where to start"). The Scylla engine
>> aims
>>> to even the playing field by making this data available and completely
>> free
>>> for everyone. The feed is meant to power threat intelligence engines to
>> aid
>>> in the defense of both large corporate networks, but also be accessible
>> to
>>> an average user who wants to check what information of theirs has been
>>> leaked. It's a passion project of mine and have been working on it for
>>> several months already. We have several terabytes of data and good
>>> attention from the infosec community.
>>> 
>>> Anyway, sorry for the brain dump above, but I suppose I should ma

[BUGS] community.zones.apache.org/map is NOT updating.

[Dave Fisher]

Hi -

Does anyone know what process updates 
http://community.zones.apache.org/map.html? I updated my location in my FOAF on 
2019-03-25 11:29:49 -0700 and this has not been changed on the map. None of my 
FOAF changes from that date made it. I can’t say how long in has been broken 
since my prior change was 2011-08-12 16:03:43 -0700

Did this used to run from minotaur in someone’s home?

Regards,
Dave

> On Jun 27, 2019, at 10:01 AM, Dave Fisher  wrote:
> 
> Hi Claude,
> 
> For committers: http://community.zones.apache.org/map.html
> 
> I see you in Galway …
> 
> Swapnil - putting Apache Locals on a similar map would be super cool.
> 
> Regards,
> Dave
> 
>> On Jun 27, 2019, at 3:24 AM, Claude Warren  wrote:
>> 
>> As a developer in a small city (Galway, IE) I can't think of another Apache
>> developer in the area.  I am certain there must be some and I know of OS
>> developers that are not Apache devs.  Is there a mechanism where by Apache
>> committers may locate other committers in their area?  Without this
>> capability I don't see how I could build an ALC team.  It would be nice if
>> I could reach out directly to local developers.
>> 
>> However, I am very interested in this idea.
>> 
>> Claude
>> 
>> 
>> On Thu, Jun 27, 2019 at 8:03 AM Swapnil M Mane 
>> wrote:
>> 
>>> Thanks very much Andrew for showing the interest.
>>> 
>>> Glad to hear from you Pranay, thanks so much for your comments.
>>> 
>>> @Team,
>>> I will share more details on how to proceed further on this soon (waiting
>>> for getting some more inputs from the community).
>>> 
>>> 
>>> - Best Regards,
>>> Swapnil M Mane
>>> 
>>> 
>>> 
>>> On Thu, Jun 27, 2019 at 12:04 PM Pranay Pandey 
>>> wrote:
>>> 
>>>> Hi Swapnil,
>>>> 
>>>> This is a fantastic idea and need of the hour for sure. This concept will
>>>> help to spread the word Apache across the world. I will be glad to
>>>> participate and help.
>>>> 
>>>> Best Regards,
>>>> Pranay
>>>> --
>>>> Pranay Pandey
>>>> Mobile : +919826035576
>>>> Skype: pranay.pandey
>>>> Linkedin: http://in.linkedin.com/in/pranaypandey
>>>> Twitter: @pandeypranay
>>>> 
>>>> 
>>>> 
>>>> On Wed, Jun 26, 2019 at 11:07 AM Swapnil M Mane >>> 
>>>> wrote:
>>>> 
>>>>> Hello team,
>>>>> 
>>>>> Recently, I got the opportunity to explore the possibility of having
>>>>> roadshow in India.
>>>>> During this process, I faced some challenges in contacting the local
>>>>> Apache
>>>>> people and committers,
>>>>> these challenges and my previous experiences (with other communities and
>>>>> student community)
>>>>> gives birth to the idea of forming the Apache Local Community (ALC).
>>>>> 
>>>>> ALC will be similar to Google Developer Group [1], Facebook Developer
>>>>> Circles [2], Mozilla Reps [3],
>>>>> you can find the local GDG [4] and Developer Circles [5].
>>>>> 
>>>>> *What is ALC*
>>>>> ALC is a local group of Apache (Open Source), enthusiast. Each local
>>> group
>>>>> will be called as ALC chapter.
>>>>> 
>>>>> *Role of ALC*
>>>>> -- Spread the awareness on Apache in the local community.
>>>>> -- Host various events for local open source lovers (at least should
>>> have
>>>>> one monthly meetup).
>>>>> -- Share the details about ASF, The Apache Way, and various Apache's
>>>>> projects in local students, developers, and the business community.
>>>>> -- Bring together project users and developers
>>>>> 
>>>>> *How ALC will be formed*
>>>>> Each town/city will strictly have single ALC chapter.
>>>>> If ALC chapter doesn't exist in the town, the interested volunteer can
>>>>> contact ALC committee via form or mail to form it.
>>>>> An ALC chapter will be led by a community manager.
>>>>> 
>>>>> *Benefits of ALC*
>>>>> -- We have limited ApacheCon and Roadshow, the ALC will open the doors
>>> for
>>>>> having frequent and small events.
>>>>> -- It will be a platform for committers from different projects (li

Re: [Proposal] Apache Local Community

[Dave Fisher]

Hi Claude,

For committers: http://community.zones.apache.org/map.html

I see you in Galway …

Swapnil - putting Apache Locals on a similar map would be super cool.

Regards,
Dave

> On Jun 27, 2019, at 3:24 AM, Claude Warren  wrote:
> 
> As a developer in a small city (Galway, IE) I can't think of another Apache
> developer in the area.  I am certain there must be some and I know of OS
> developers that are not Apache devs.  Is there a mechanism where by Apache
> committers may locate other committers in their area?  Without this
> capability I don't see how I could build an ALC team.  It would be nice if
> I could reach out directly to local developers.
> 
> However, I am very interested in this idea.
> 
> Claude
> 
> 
> On Thu, Jun 27, 2019 at 8:03 AM Swapnil M Mane 
> wrote:
> 
>> Thanks very much Andrew for showing the interest.
>> 
>> Glad to hear from you Pranay, thanks so much for your comments.
>> 
>> @Team,
>> I will share more details on how to proceed further on this soon (waiting
>> for getting some more inputs from the community).
>> 
>> 
>> - Best Regards,
>> Swapnil M Mane
>> 
>> 
>> 
>> On Thu, Jun 27, 2019 at 12:04 PM Pranay Pandey 
>> wrote:
>> 
>>> Hi Swapnil,
>>> 
>>> This is a fantastic idea and need of the hour for sure. This concept will
>>> help to spread the word Apache across the world. I will be glad to
>>> participate and help.
>>> 
>>> Best Regards,
>>> Pranay
>>> --
>>> Pranay Pandey
>>> Mobile : +919826035576
>>> Skype: pranay.pandey
>>> Linkedin: http://in.linkedin.com/in/pranaypandey
>>> Twitter: @pandeypranay
>>> 
>>> 
>>> 
>>> On Wed, Jun 26, 2019 at 11:07 AM Swapnil M Mane >> 
>>> wrote:
>>> 
>>>> Hello team,
>>>> 
>>>> Recently, I got the opportunity to explore the possibility of having
>>>> roadshow in India.
>>>> During this process, I faced some challenges in contacting the local
>>>> Apache
>>>> people and committers,
>>>> these challenges and my previous experiences (with other communities and
>>>> student community)
>>>> gives birth to the idea of forming the Apache Local Community (ALC).
>>>> 
>>>> ALC will be similar to Google Developer Group [1], Facebook Developer
>>>> Circles [2], Mozilla Reps [3],
>>>> you can find the local GDG [4] and Developer Circles [5].
>>>> 
>>>> *What is ALC*
>>>> ALC is a local group of Apache (Open Source), enthusiast. Each local
>> group
>>>> will be called as ALC chapter.
>>>> 
>>>> *Role of ALC*
>>>> -- Spread the awareness on Apache in the local community.
>>>> -- Host various events for local open source lovers (at least should
>> have
>>>> one monthly meetup).
>>>> -- Share the details about ASF, The Apache Way, and various Apache's
>>>> projects in local students, developers, and the business community.
>>>> -- Bring together project users and developers
>>>> 
>>>> *How ALC will be formed*
>>>> Each town/city will strictly have single ALC chapter.
>>>> If ALC chapter doesn't exist in the town, the interested volunteer can
>>>> contact ALC committee via form or mail to form it.
>>>> An ALC chapter will be led by a community manager.
>>>> 
>>>> *Benefits of ALC*
>>>> -- We have limited ApacheCon and Roadshow, the ALC will open the doors
>> for
>>>> having frequent and small events.
>>>> -- It will be a platform for committers from different projects (living
>> in
>>>> the same town/city) to meet and exchange knowledge, thoughts, and ideas.
>>>> Currently, it happens the committer of one apache project doesn't know
>>>> much
>>>> about the committer from another project (both belongs to the same town
>> ;)
>>>> -- Building community, as the Apache maxim "Community Over Code".
>>>> 
>>>> These all are very initial ideas if we planned to proceed with this, as
>> a
>>>> community, we can work details of defining roles and responsibility of
>>>> ALC,
>>>> the process of forming ALC chapters, how the ALC chapters will function
>>>> (community manager/lead of ALC chapters), etc.
>>>> 
>>>> I am aware of Apa

Please move DI notifications to the diversity list

[Dave Fisher]

Hi -

Since diversity and inclusion is no longer comdev please move JIRA 
notifications to diversity@.

Regards,
Dave

Sent from my iPhone

> On May 31, 2019, at 6:29 PM, Andrew Musselman (JIRA)  wrote:
> 
> 
>[ 
> https://issues.apache.org/jira/browse/DI-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853532#comment-16853532
>  ] 
> 
> Andrew Musselman commented on DI-7:
> ---
> 
> Ijeoma Oluo
> 
> Seattle
> 
> English
> 
> D, how to talk about racism and equity
> 
> [http://www.ijeomaoluo.com|http://www.ijeomaoluo.com/]
> 
> Contact form on her home page
> 
>  
> 
>> Curating a list of speakers for ApacheCon
>> -
>> 
>>Key: DI-7
>>URL: https://issues.apache.org/jira/browse/DI-7
>>Project: Diversity and Inclusion
>> Issue Type: Wish
>> Components: knowledge, resources
>>   Reporter: Griselda Cuevas Zambrano
>>   Assignee: Griselda Cuevas Zambrano
>>   Priority: Normal
>> Labels: events, how-to, speakers
>>  Original Estimate: 168h
>> Remaining Estimate: 168h
>> 
>> Hi folks - let's curate a list of speakers we'd like to invite to discuss 
>> D with the ASF community. We can use this list to invite folks to events 
>> like ApacheCon, or project summits, and also maybe create a Speakers series? 
>>  
>> Ok, all you need to do is list this info: 
>> * Speaker:
>> * Location:
>> * Language: 
>> * Topic:
>> * URL: (can be a talk/website/twitter/etc)
>> * How to contact: (if you don't know put don't know)
>> Cheers
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: A little annoying development with emails and "integration" with other tooling ...

[Dave Fisher]

Hi -

I’ve submitted INFRA-18350 Gitbox - Improve Generated Email Subjects

I’ve suggested a shorter, more consistent email subject. Threading is being 
worked on slowly.

Regards,
Dave

> On May 8, 2019, at 7:15 AM, Dave Fisher  wrote:
> 
> Hi -
> 
> I find it nearly impossible to follow GitHub (GitBox) emails. I know Infra 
> has done some work on threading these which has improved the situation. More 
> needs to be done to improve the subjects. Perhaps we can also create digest 
> emails.
> 
> For JIRA I guess since I’ve used JIRA off and on since JIRA version 1 AND it 
> is easier to have a meaningful subject I’m less concerned.
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On May 8, 2019, at 4:24 AM, Christofer Dutz  
>> wrote:
>> 
>> Hi Lars,
>> 
>> I agree that Jira emails have been there for quite some time. 
>> It seems as more projects are starting to discuss things in jira.
>> What I'm more referring to is that with the jira issues, it would be great 
>> if the title of these emails could be stripped down drastically.
>> Could imagine the email of the user doing something being used as sender and 
>> for example strip down the whole "JIRA Christofer Dutz commented on 
>> PLC4X-0815: yadda yadda" to something like "PLC4X-0815: yadda yadda (New 
>> comment)"
>> It's all this nonsense prefix to the interesting part of the mail title I'm 
>> mostly criticizing. 
>> Besides the lack of content in the GitHub emails, which is a second issue 
>> for me.
>> 
>> Chris
>> 
>> 
>> 
>> Am 08.05.19, 12:05 schrieb "Lars Francke" :
>> 
>>   Hi Chris,
>> 
>>   I partially agree with you.
>> 
>>   I agree with Github pull requests. They are hard to follow and hard to read
>>   (and I don't only mean the mails but also on the site itself).
>> 
>>   I disagree with the Jira mails though. I wouldn't really know how to
>>   improve those and I like that the discussion is part of the issue itself
>>   and I don't agree that this has changed recently. Jira discussions have
>>   been happening like this for years at least in the projects I'm working on,
>>   so nothing really has changed there. They can't really put much content in
>>   the subject?
>> 
>>   I also dislike that it's getting harder to keep track of things with
>>   Github + Jira. There are open Jira issues with "Pending Review" (or
>>   similar) state and there are open Pull requests where there used to be only
>>   one place.
>> 
>>   Do you have any suggestions on how to improve this?
>> 
>>   Cheers,
>>   Lars
>> 
>>   On Wed, May 8, 2019 at 10:13 AM Christofer Dutz 
>>   wrote:
>> 
>>> Hi all,
>>> 
>>> I have noticed in a lot of projects I am involved in, that my active
>>> participation has dropped with more and more communities shifting to
>>> discuss things in jira and using github code reviews.
>>> 
>>> Usually I used the title of emails to decide on which discussions I should
>>> follow … this worked great till all topics sort of start with:
>>> 
>>> [jira][someoperation][somproject-someissueid] some description
>>> 
>>> Or even worse:
>>> 
>>> [GitHub] [someproject] someone commented on a change in pull request
>>> #someid: some description
>>> 
>>> …
>>> 
>>> Is it just me, or do you also have problems mass-scanning mailinglists
>>> with these titles in most of their emails?
>>> I mean … I am currently following about 30-40 email lists and I really
>>> have to be efficient in keeping up to date.
>>> 
>>> For me I think it’s really damaging as I am not willing to manually go
>>> through all the Jira issues and github pull requests or github issues to
>>> scan through masses of emails to find the usually minimal information they
>>> contain.
>>> Especially github reviews really piss me off as the net information
>>> content for each of these emails is minimal their use is minimal as the
>>> context isn’t contained and I have to click on 10 emails to get the point
>>> of one single review.
>>> 
>>> I think it’s great to be open to changes, but we really have to ensure we
>>> don’t lose what has been good.
>>> 
>>> What do you think?
>>> 
>>> Chris
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: A little annoying development with emails and "integration" with other tooling ...

[Dave Fisher]

Hi -

I find it nearly impossible to follow GitHub (GitBox) emails. I know Infra has 
done some work on threading these which has improved the situation. More needs 
to be done to improve the subjects. Perhaps we can also create digest emails.

For JIRA I guess since I’ve used JIRA off and on since JIRA version 1 AND it is 
easier to have a meaningful subject I’m less concerned.

Regards,
Dave

Sent from my iPhone

> On May 8, 2019, at 4:24 AM, Christofer Dutz  wrote:
> 
> Hi Lars,
> 
> I agree that Jira emails have been there for quite some time. 
> It seems as more projects are starting to discuss things in jira.
> What I'm more referring to is that with the jira issues, it would be great if 
> the title of these emails could be stripped down drastically.
> Could imagine the email of the user doing something being used as sender and 
> for example strip down the whole "JIRA Christofer Dutz commented on 
> PLC4X-0815: yadda yadda" to something like "PLC4X-0815: yadda yadda (New 
> comment)"
> It's all this nonsense prefix to the interesting part of the mail title I'm 
> mostly criticizing. 
> Besides the lack of content in the GitHub emails, which is a second issue for 
> me.
> 
> Chris
> 
> 
> 
> Am 08.05.19, 12:05 schrieb "Lars Francke" :
> 
>Hi Chris,
> 
>I partially agree with you.
> 
>I agree with Github pull requests. They are hard to follow and hard to read
>(and I don't only mean the mails but also on the site itself).
> 
>I disagree with the Jira mails though. I wouldn't really know how to
>improve those and I like that the discussion is part of the issue itself
>and I don't agree that this has changed recently. Jira discussions have
>been happening like this for years at least in the projects I'm working on,
>so nothing really has changed there. They can't really put much content in
>the subject?
> 
>I also dislike that it's getting harder to keep track of things with
>Github + Jira. There are open Jira issues with "Pending Review" (or
>similar) state and there are open Pull requests where there used to be only
>one place.
> 
>Do you have any suggestions on how to improve this?
> 
>Cheers,
>Lars
> 
>On Wed, May 8, 2019 at 10:13 AM Christofer Dutz 
>wrote:
> 
>> Hi all,
>> 
>> I have noticed in a lot of projects I am involved in, that my active
>> participation has dropped with more and more communities shifting to
>> discuss things in jira and using github code reviews.
>> 
>> Usually I used the title of emails to decide on which discussions I should
>> follow … this worked great till all topics sort of start with:
>> 
>> [jira][someoperation][somproject-someissueid] some description
>> 
>> Or even worse:
>> 
>> [GitHub] [someproject] someone commented on a change in pull request
>> #someid: some description
>> 
>> …
>> 
>> Is it just me, or do you also have problems mass-scanning mailinglists
>> with these titles in most of their emails?
>> I mean … I am currently following about 30-40 email lists and I really
>> have to be efficient in keeping up to date.
>> 
>> For me I think it’s really damaging as I am not willing to manually go
>> through all the Jira issues and github pull requests or github issues to
>> scan through masses of emails to find the usually minimal information they
>> contain.
>> Especially github reviews really piss me off as the net information
>> content for each of these emails is minimal their use is minimal as the
>> context isn’t contained and I have to click on 10 emails to get the point
>> of one single review.
>> 
>> I think it’s great to be open to changes, but we really have to ensure we
>> don’t lose what has been good.
>> 
>> What do you think?
>> 
>> Chris
>> 
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Why should D be a president's committee?

[Dave Fisher]

Hi Ross,

Forgive me if this opens up the subject more than needed, but I have a question.

How do you view this new Diversity & Inclusion committee with respect to the 
code of conduct and 
https://www.apache.org/foundation/policies/conduct#reporting-guidelines where a 
list of contacts are provided.

Is the new D committee meant to be separate from reporting/“enforcement” or 
not? Your arguments around legal situations involving law enforcement 
potentially implies a mixing of policy evaluation and enforcement.

Regards,
Dave

> On May 1, 2019, at 7:31 AM, Ross Gardler  wrote:
> 
> Good points so far.  One that I believe has been missed...
> 
> Board committees have 9 bosses. PMCs have potentially many more. Presidents 
> committees have 1.
> 
> In other words, a Presidents committee can get things done more quickly in 
> difficult or controversial spaces, especially in things that do not present a 
> binary correct/incorrect set of choices.
> 
> As noted by others there is significant oversight from the board via monthly 
> reports. Plenty of opportunity for course correction as result. Any objection 
> by any one of the nine is dealt with by President, allowing the committee to 
> get on with their work within the boundaries agreed with the president.
> 
> This requires a level of trust in the President, and their delegates.
> 
> Ross
> 
> Get Outlook for Android<https://aka.ms/ghei36>
> 
> 
> From: Shane Curcuru 
> Sent: Wednesday, May 1, 2019 6:23:34 AM
> To: dev@community.apache.org
> Subject: Re: Why should D be a president's committee?
> 
> The most important question is: where do the people who are currently
> most active doing the real work of the survey and organizing
> informational materials on diversity@ want to do that work?  Ensuring
> they have a productive space and framework to work is the first thing to
> solve.   That said...
> 
> Myrle Krantz wrote on 5/1/19 7:06 AM:
> ...snip...
>> * Make it a sub-committee of ComDev.
> 
> This is nothing more than a page on community.a.o and the diversity@
> mailing list.  We already effectively have that.  The only difference
> would be having a formal page on the website that lists who's there,
> essentially copying what we've done in the mailing list.
> 
> In terms of powers, none in particular.  Membership changes by the PMC
> voting in new PMC members (or allowing committers to participate, etc.)
> Reports would be part of the quarterly ComDev report.
> 
>> * Make it a president's committee.
> 
> The proposal is to also name a VP of that committee as well.  The VP is
> an officer, and can perform duties for the ASF within the scope of
> whatever charter the board originally creates the VP officer with.
> 
> Historically, we've had the board create *new VP roles* with a title and
> description, and appoint the first person to that role.  For President's
> committees and other VPs reporting to the President, we've had the
> President thereafter simply make new appointments to existing roles
> directly (always reported in board reports).
> 
> President's committees can be changed by the President at any point, or
> by the VP in charge if specifically authorized to do so.  Also, since
> President's committees are mostly about operations, we have examples of
> officers like this having regular annual budgets and signing authority.
> 
> They cannot release software (publicly).  They could have a separate
> website and mailing lists.  President's committees report monthly.
> 
>> * Make it it's own PMC.
> 
> This requires a normal board resolution, and would act like any other
> PMC, especially in terms of managing PMC or committer membership.  We've
> done straight-to-PMC before (i.e. not going through Incubation), it just
> needs the scope description of the PMC and the list of VP and members.
> 
> They could release software and all the usual PMC things, and they
> report to the board quarterly.
> 
> 
> 
> Elsethread, Mark also mentioned a board committee.  They have the powers
> of the board.  Changing board committees (normally) takes a board
> resolution, meaning it takes more time to add/remove people.  They
> report monthly to the board.
> 
> While President's committees have a broad scope of operations, often
> looking across the whole ASF, they do not have direct power to generally
> set policies across other projects.  Board committees, on the other
> hand, could directly enact and enforce policies across projects.
> 
> 
> 
> Personally, I'm +1 for a President's committee.  Right now, we need a
> place where people actively doing productive work can do so.
> President's committees provide 

Re: IP address block

[Dave Fisher]

I forwarded this to the correct list.

Bcc dev@community

Sent from my iPhone

> On Apr 15, 2019, at 11:46 AM, KIVANÇ ERDEM NALBANTOĞLU 
>  wrote:
> 
> Hi Team
> 
> My name is Kıvanç and I am working at  information technology and 
> communication authority in Turkey.
> 
> When we can try to reach and download something on your web site we cannot 
> acccess to your web site  from our public IP address , we also talked with 
> our internet provider and they said that traffic pass from ISP . we suspect 
> that our public IP address is dropped on network layer so please forward this 
> e-mail to releated network Security team on your site to control our IP 
> address is dropped or not by your systems.
> 
> Our public IP address is 212.156.76.188 and we are trying to access 
> www.arache.org (40.79.78.1)
> 
> Thanks.
> 
> 
> [BTK]   KIVANÇ ERDEM NALBANTOĞLU
> BT Sözleşmeli Personeli
> Teknik İşletme Dairesi Başkanlığı
> 
> Tel:
> Adres: Eskişehir Yolu 10.Km No: 276 Posta Kodu: 06530 Çankaya/Ankara
> 
> www.btk.gov.tr
> _ _ _ __ _ _ _
> 
> 
> 
> 
> 
> 
> YASAL UYARI:
> Bu e-postada yer alan bilgiler, beraberinde iletilen tüm bilgi, onay ve her 
> türlü formattaki dosyalar, gizlidir ve kişiye özel olabilir ve sadece 
> gönderildiği kişi ya da kuruma ya da bu bilgileri kullanmaya ya da almaya 
> yetkili diğer kişilere özeldir. Eğer siz doğru kişi değilseniz, bu e-postayı 
> açıklamak, kopyalamak, dağıtmak ya da içeriğine istinaden işlem yapmak 
> tümüyle yasaktır ve kanuna aykırı olabilir. Bu nedenle bu e-postayı 
> yanlışlıkla aldıysanız, bu durumu derhal gönderene haber veriniz ve e-postayı 
> siliniz. Bu e-postanın tarafınıza yanlışlıkla iletilmiş olması yüzünden 
> e-postanın gizli ve kişiye özel niteliği kaybolmaz ya da bu niteliğinden 
> vazgeçilmez. BTK, bu e-postada yer alan bilgilerin ya da e-postanın 
> kendisinin usulüne göre ve/veya tam iletiminden ya da e-postanın alınmasında 
> yaşanan herhangi bir gecikmeden sorumlu değildir. BTK bu e-postanın içeriği 
> ile ilgili olarak hiç bir hukuksal sorumluluğu kabul etmez. BTK, virüs 
> filtreleme uygulamakla birlikte, e-postanın virüs içermediğini garanti ya da 
> temin etmez.
> 
> DISCLAIMER:
> The information, consent and file attached thereto, contained in this e-mail 
> is confidential and may be legally privileged, and is intended solely for the 
> use of the individual or entity to whom it is addressed and others authorized 
> to use it or receive it. If you are not the intended recipient, you are 
> hereby notified that any disclosure, copying, distribution or taking action 
> in reliance of the contents of this e-mail is strictly prohibited and may be 
> unlawful. If therefore you have received this e-mail in error, please notify 
> the sender immediately and then delete it. Confidentiality and legal 
> privileges are not waived or lost even if you have been accidentally 
> transmitted by this e-mail. ICTA is not responsible for the proper and/or 
> complete transmission of the information contained in this e-mail or of the 
> e-mail itself nor in any delay in its receipt. ICTA does not accept any form 
> of legal responsibility for the content of this e-mail. Whilst ICTA does 
> apply virus filtering, it provides no guarantee or warranty that the e-mail 
> is virus-free.
> 


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

Re: Feature request: Git/GH Issues in reporter.apache.org ?

[Dave Fisher]

The git commit data is available, but it is not in the tool. Have a look at 
https://gitbox.apache.org/repositories.json

Regards,
Dave

> On Apr 10, 2019, at 9:51 AM, sujan mondal  wrote:
> 
> Hello
> 
> On Wed, Apr 10, 2019, 10:47 PM Joan Touzet  wrote:
> 
>> Hi everyone,
>> 
>> As a newly-elected board member, I'm discovering a blind spot
>> in the reporter.apache.org tool, specifically for projects that
>> have transitioned to git for version control and GitHub issues
>> for issue management.
>> 
>> I believe reporter only currently pulls down commit statistics
>> from svn, and issue data from JIRA. This makes it hard to know
>> whether a project is making active progress in drawing down
>> their ticket backlog or how active their repositor(y|ies) are.
>> 
>> Apparently, the code is in Python and here:
>> 
>> https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk
>> 
>> and patches are welcome (TM), but I don't have the energy to
>> work on this myself.
>> 
>> Is anyone able to team up with Daniel Gruno to help add this
>> functionality to reporter?
>> 
>> -Joan "more metrics" Touzet
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>> 
>> 


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

Re: [CHICAGO] Roadshow schedule is up

[Dave Fisher]

Bob is a Foundation Member. You could grant access to all Members, right?

Sent from my iPhone

> On Apr 8, 2019, at 8:29 AM, Rich Bowen  wrote:
> 
> This remains an unsolved problem - granting write access to our event 
> websites to people who are not ComDev committers, without voting them in. 
> This seems like something that needs to happen - it's in the way of getting 
> work done - but the way that ACLs are applied makes us required to jump 
> through the hoops.
> 
> Any suggestions of how to fix this quickly?
> 
> 
>  Forwarded Message 
> Subject:Re: [CHICAGO] Roadshow schedule is up
> Date:Thu, 4 Apr 2019 18:07:42 -0500
> From:Bob Paulin 
> Reply-To:plann...@apachecon.com
> To:plann...@apachecon.com
> 
> 
> 
> Hi,
> 
> Can anyone grant me access (username is bob) on the apachecon repo where the 
> roadshow is hosted?  I need to update someone's employer before they get in 
> trouble.  Thanks!
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org


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

Re: on "meritocracy"

[Dave Fisher]

Top-post:

Couldn’t this be made a President’s committee now and the board can chat about 
it elsewhere until the next board meeting in a few weeks? The board could even 
defer until there are Policy recommendations.

(I’m not excited about reading yet another passionate Jim/Sam debate about 
which type of committee at this moment.)

Regards,
Dave

> On Apr 2, 2019, at 8:46 AM, Patricia Shanahan  wrote:
> 
> On 4/2/2019 8:12 AM, Bertrand Delacretaz wrote:
> ...
>> It's just that the comdev PMC is responsible for oversight and
>> reporting on those new initiatives, and it keeps things simple for
>> now.
> 
> That is exactly what troubles me about making the new initiative part of 
> ComDev.
> 
> There seems to me to be a risk of going back to the "Do we have a problem? 
> Even if we have a problem do we really need to do anything about it?" stage 
> every time the group tries to do anything, including reporting progress to 
> the board, and requesting resources from the board.
> 
> At best, comdev PMC oversight and reporting would be mostly harmless. They 
> would just pass through whatever the group would have sent directly to the 
> board, only costing time. At worst, it could make the current initiative go 
> the way of all previous diversity efforts, by discouraging and sapping the 
> energy of the initiative's leadership.
> 
> The risk of anything other than direct access to the board seems too high.
> 
> [I have not attempted to join the initiative only because I do not have any 
> expertise in the area of solutions. I have been a woman in computing, in 
> various ways, for over 50 years. I want the current initiative to have the 
> best possible chance of making a difference.]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: tuweni

[Dave Fisher]

Hi Shi Jinghai,

The project is literally starting at Apache now, I’m one of the mentors and 
don’t know the project’s deep technical details, I’m involved to get the 
project started on the Apache Way.

Please subscribe to the new dev list by sending an email to 
dev-subscr...@tuweni.apache.org <mailto:dev-subscr...@tuweni.apache.org> . You 
can then ask what you want. Please be patient as the team signs up.

Regards,
Dave

> On Apr 1, 2019, at 10:14 PM, Shi Jinghai  wrote:
> 
> Great!!!
> 
> On the BPEL part, could I publish a drools jar as a contract to tuweni?
> 
> 
> -邮件原件-
> 发件人: Oleg Tikhonov [mailto:olegtikho...@gmail.com] 
> 发送时间: 2019年3月31日 22:55
> 收件人: dev@community.apache.org
> 抄送: Felix Schumacher
> 主题: Re: tuweni
> 
> Thanks for the update !!!
> Looks very good. Really appreciate that!
> 
> BR,
> Oleg
> 
> On Sun, Mar 31, 2019 at 5:38 PM Dave Fisher  wrote:
> 
>> Hi,
>> 
>> Tuweni just entered Incubation last week and resources are mostly
>> allocated. We are starting to onboard the committers this coming week.
>> 
>> The status page is coming soon and I’ll be looking into the clutch start
>> date bug.
>> 
>> The proposal is here: https://wiki.apache.org/incubator/CavaProposal
>> 
>> The podling was renamed before starting. It’s a blockchain project.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Mar 31, 2019, at 1:46 AM, Oleg Tikhonov 
>> wrote:
>>> 
>>> Thank you all !!!
>>> Very impressed :-)
>>> 
>>> My first intention was - to have a look at source code, read a readme
>> etc.
>>> Look forward for more progress from where I could help.
>>> 
>>> Thanks again.
>>> Best regards,
>>> Oleg
>>> 
>>> BTW:
>>> https://incubator.apache.org/clutch/tuweni.html
>>> I guess the creation date should be updated to "now" instead of "
>> Updated:
>>> 01/01/1970 "
>>> 
>>> 
>>> On Sun, Mar 31, 2019 at 11:22 AM Felix Schumacher <
>>> felix.schumac...@internetallee.de> wrote:
>>> 
>>>> 
>>>> 
>>>> Am 31. März 2019 09:13:30 MESZ schrieb Oleg Tikhonov :
>>>>> Hi guys,
>>>>> I'm wondering if somebody knows where can I get more info about this
>>>>> project:
>>>>> https://incubator.apache.org/projects/tuweni.html
>>>>> 
>>>>> The link does not seem to work.
>>>> 
>>>> This seems to be a rather new project. Maybe the web page has not been
>>>> uploaded yet. The mailing list seems to work, though.
>>>> 
>>>> https://lists.apache.org/list.html?d...@tuweni.apache.org
>>>> 
>>>> Regards
>>>> Felix
>>>> 
>>>>> 
>>>>> Thanks in advance,
>>>>> Oleg
>>>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Re: tuweni

[Dave Fisher]

Hi -

> On Mar 31, 2019, at 1:46 AM, Oleg Tikhonov  wrote:
> 
> Thank you all !!!
> Very impressed :-)
> 
> My first intention was - to have a look at source code, read a readme etc.
> Look forward for more progress from where I could help.
> 
> Thanks again.
> Best regards,
> Oleg
> 
> BTW:
> https://incubator.apache.org/clutch/tuweni.html
> I guess the creation date should be updated to "now" instead of " Updated:
> 01/01/1970 “

These values are from gitbox.apache.org and this is because the repositories 
are fresh and empty. As soon as content is added the date will be fixed.

It looks like we somehow got a second repos: 
incubator-tuweni-incubator-tuwenigit

Including users@Infra and general@incubator

Regards,
Dave

> 
> 
> On Sun, Mar 31, 2019 at 11:22 AM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
> 
>> 
>> 
>> Am 31. März 2019 09:13:30 MESZ schrieb Oleg Tikhonov :
>>> Hi guys,
>>> I'm wondering if somebody knows where can I get more info about this
>>> project:
>>> https://incubator.apache.org/projects/tuweni.html
>>> 
>>> The link does not seem to work.
>> 
>> This seems to be a rather new project. Maybe the web page has not been
>> uploaded yet. The mailing list seems to work, though.
>> 
>> https://lists.apache.org/list.html?d...@tuweni.apache.org
>> 
>> Regards
>> Felix
>> 
>>> 
>>> Thanks in advance,
>>> Oleg
>> 


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

Re: tuweni

[Dave Fisher]

Hi,

Tuweni just entered Incubation last week and resources are mostly allocated. We 
are starting to onboard the committers this coming week.

The status page is coming soon and I’ll be looking into the clutch start date 
bug.

The proposal is here: https://wiki.apache.org/incubator/CavaProposal

The podling was renamed before starting. It’s a blockchain project.

Regards,
Dave

Sent from my iPhone

> On Mar 31, 2019, at 1:46 AM, Oleg Tikhonov  wrote:
> 
> Thank you all !!!
> Very impressed :-)
> 
> My first intention was - to have a look at source code, read a readme etc.
> Look forward for more progress from where I could help.
> 
> Thanks again.
> Best regards,
> Oleg
> 
> BTW:
> https://incubator.apache.org/clutch/tuweni.html
> I guess the creation date should be updated to "now" instead of " Updated:
> 01/01/1970 "
> 
> 
> On Sun, Mar 31, 2019 at 11:22 AM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
> 
>> 
>> 
>> Am 31. März 2019 09:13:30 MESZ schrieb Oleg Tikhonov :
>>> Hi guys,
>>> I'm wondering if somebody knows where can I get more info about this
>>> project:
>>> https://incubator.apache.org/projects/tuweni.html
>>> 
>>> The link does not seem to work.
>> 
>> This seems to be a rather new project. Maybe the web page has not been
>> uploaded yet. The mailing list seems to work, though.
>> 
>> https://lists.apache.org/list.html?d...@tuweni.apache.org
>> 
>> Regards
>> Felix
>> 
>>> 
>>> Thanks in advance,
>>> Oleg
>> 

Re: on "meritocracy"

[Dave Fisher]

> On Mar 30, 2019, at 11:57 AM, Wade Chandler  wrote:
> 
> On Sat, Mar 30, 2019, 14:44 Naomi Slater  wrote:
> 
>> On Sat, 30 Mar 2019 at 19:28, Myrle Krantz  wrote:
>> 
>>> On Sat, Mar 30, 2019 at 7:20 PM Jim Jagielski  wrote:
>>> 
>>>> 
>>>> 
>>>>> On Mar 30, 2019, at 10:41 AM, Naomi Slater 
>> wrote:
>>>>> 
>>>>> I've done a
>>>>> lot of work for Apache and this is the first time I recall seeing
>> your
>>>>> name. so I hope you will excuse me for not thinking your imputation
>>>> carries
>>>>> much weight
>>>>> 
>>>> 
>>>> Please don't go there.
>>>> 
>>> 
>>> JIm, that was directed at Wade, not you.
>>> 
>> 
>> and my point wasn't "I've done more work than you so I am right". my point
>> was "who are you to tell me I don't care about this organization because I
>> 'dare' to criticize 'the meritocracy'". which I believe is a perfectly
>> reasonable comment in reply to such a preposterous claim
>> 
> 
> And mine was there is a line in this thread attacking the way a lot of very
> inclusive people work here, and that line is like "your points have no
> merit, but we'll make changes and drive them, that affect the whole org,
> while using meritocracy while saying it is bad at lower levels", and in
> this case it is everyone's concern even if they are not working on the
> specific thing you are, because it impacts the whole/everyone working on
> something at Apache, and is also directly related to my point on the
> possibility to exist for overreach and overreaction considering that.
> 
> Folks chose to throw around weight with various phrases such as "because
> the President" and "policing". Where is the plan for what this looks like
> given these mandates?

Well I happen not to like that aspect of how the Incubator is currently 
working. I know it is frustrating for you. I woke up to that thread...

Regards,
Dave

> 
> Wade


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

Re: on "meritocracy"

[Dave Fisher]

Hi -

One observation is that those who seem trollish may also have something else 
going on somewhere else in the overall Apache Community and it might be those 
annoyances for which they may or may not ever have resolution that may be 
“coloring” their interaction. If you are aware of it then you don’t even write 
the email that you then delete before sending. (There’s a thread on general@ 
that shows a current example. There was an email early in this thread that is 
an ancient example.)

Slowing one's own roll and not answering every email is a lesson I learned from 
prior passionate debates within projects. It’s part of the ethos of a global 
community to let the world spin and not have too many messages appearing in the 
morning for others on the list.

I’ll support whatever is agreed to on replacing the phrase “meritocracy” and 
will help to see that Incubator content is updated appropriately.

Regards,
Dave

> On Mar 30, 2019, at 11:28 AM, Myrle Krantz  wrote:
> 
> On Sat, Mar 30, 2019 at 7:20 PM Jim Jagielski  wrote:
> 
>> 
>> 
>>> On Mar 30, 2019, at 10:41 AM, Naomi Slater  wrote:
>>> 
>>> I've done a
>>> lot of work for Apache and this is the first time I recall seeing your
>>> name. so I hope you will excuse me for not thinking your imputation
>> carries
>>> much weight
>>> 
>> 
>> Please don't go there.
>> 
> 
> JIm, that was directed at Wade, not you.
> 
> Best,
> Myrle


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

Re: on "meritocracy"

[Dave Fisher]

+0 - as in I support this but don’t have time to do so directly.

I will support any surveys or discussions that might come to the Incubator or 
any of the PMCs of which I’m a member.

Regards,
Dave

> 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 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
> 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 at the ASF*
> *I want to be part of this. *
> 1) Define purpose, values and objectives for a D 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 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
>> of band is possible, but there is no reason here to force the issue).
>> The schedule is here:
>> 
>> https://svn.apache.org/repos/private/committers/board/calendar.txt
>

Re: on "meritocracy"

[Dave Fisher]

Hi -

> On Mar 28, 2019, at 10:45 AM, Ross Gardler  wrote:
> 



> Asking people to put pronoun stickers on badges might seem unnecessary to some

I’m trying to give up on guessing pronouns and attempting to always use “they” 
and “them”.

Except for Jim - Him, Jim ;-)

Regards,
Dave

> 
> 
> From: Sam Ruby 
> Sent: Thursday, March 28, 2019 10:13 AM
> To: Apache Community Dev
> Subject: Re: on "meritocracy"
> 
> Not directly a response to the below, but very much related to it.
> 
> If you go to a Node.js conference these days, the very first thing you
> do is pick up a badge.  When you do, they ask you to consider putting
> on a sticker containing your preferred pronouns.  Shortly thereafter
> you realize that the conference is qualitatively different in terms of
> inclusion - gender isn't quite a 50/50 split, but I did find myself on
> more than one occasion seated surrounded by women - north, south,
> east, west.  There also are talks, panels, open discussions on
> diversity.
> 
> There also are noticeably more people with different gender
> orientations, people of color, etc.  Not just in the audience, but
> also on the stage.
> 
> When people (generally inadvertent) make a remark that could be
> considered non-inclusive on a node mailing list, they are generally
> called on it (and quickly), and promptly apologize, and the apology is
> promptly accepted.  If there are any actions that need to be taken,
> they are identified and acted upon.
> 
> Where we, the ASF, are and continue to be is abnormal.  The difference
> from industry norms is statistically significant.  And durable.
> 
> When such topics come up here, the response is contentious and
> defensive, long winded, and generally without resolution.
> 
> Yes, you will find women at ASF conferences.  Look, there are two over
> there, and one more on the other side.  OK, so there may be some talks
> where there are more, but there are also some talks where there are
> less.
> 
> There must be something that we are doing - or not doing - which is
> causing all of this.
> 
> What saddens me is that I don't know what to suggest.
> 
> Enumerating what we are doing (such as Rich did below) is a good
> start.  But also acknowledging that we are somehow the cause if it -
> either though action or inaction - is also a necessary first step.
> 
> - Sam Ruby
> 
> 
> On Thu, Mar 28, 2019 at 12:48 PM Rich Bowen  wrote:
>> 
>> 
>> 
>> On 3/28/19 11:58 AM, Pierre Smits wrote:
>> 
>>> I find it sad that there are (board) members who keep saying that the
>>> situation must improve (because there are problems regarding Diversity and
>>> Inclusion), but when it comes to where it needs to improve (in the projects
>>> mostly) they also keep saying (here and other threads also in other fora in
>>> the past) that there is nothing to be done from the Foundation downwards to
>>> the projects because 'the projects are independent'.
>> 
>> I am not aware of any board members who have said that. Unless you're
>> construing my comment in that light. Because that is most definitely not
>> what I said.
>> 
>> The Foundation does do stuff "downwards to the projects." We have, in
>> fact, established a PMC, named "Community Development" which has that as
>> its charter.
>> 
>> Furthermore, EVERY SINGLE MONTH, there is at least one (and usually
>> several) response to a project report, encouraging them to more actively
>> pursue new committers, lower their bar to entry, actively mentor new
>> contributors, and so on.
>> 
>>> 
>>> In my book there is where the view-points of those persons go of in wrong
>>> directions. Yes, projects are expected to operate independently from
>>> outside influence. But they can not operate independently from the
>>> organisation they reside under. In a page (See [1]) of the ASF it is stated
>>> that 'the board delegates the technical direction of all projects to each
>>> PMC', but 'are expected to follow corporate policies'. This means that the
>>> policies can be created at Foundation level, and can be policed (by the
>>> Board, and/or through delegation by a specific office). If the highest body
>>> of the Foundation established a strict(er) policy on 'merit awarding'
>>> and/or 'Diversity & Inclusion' then it is obliged, with regards to these
>>> policies, to:
>>> 
>>>1. ensure that each of the lower level organisational units (OUs like
>>>projects/offices/departments, etc.) acknowledge and apply su

Re: on "meritocracy"

[Dave Fisher]

> On Mar 28, 2019, at 8:11 AM, Jim Jagielski  wrote:
> 
>> 



>>> If we are actively (or passively) discouraging diversity, then it is
>>> a problem, of course. Are we?
>>> 
>> 
>> yes. of course we are. ~5% of our committer base are women. 1 single
>> person, that we know of, is Black. compare these to the figures for the
>> industry as a whole and there is literally no other conclusion you can come
>> to
> 
> I disagree that such lack of diversity can be attributed to us discouraging 
> it.

Perhaps it is because we are not actively encouraging it.

I think that in the Incubator we may be focused on IP and Release ceremonies 
and vendor neutrality, and less focused on true community growth.

Are there resources that Comdev could provide on Best Practices from a PMC that 
has been more successful at D & I? Do we have any example?

> 
>> 
>> can you explain to me where that other 15% of women are? why do we not
>> count them amongst our committers?
>> 
> 
> I don't know... maybe they aren't driven or attracted to contributing to
> open source projects. Maybe the kinds of projects within the ASF
> are not the kinds that attract them
> 
> All this assumes that the diversity at Apache should match the "tech
> industry in North America". But why? The jobs in the tech industry
> are wide and varied... are the roles here just as wide and varied?
> Plus, you are talking about jobs vs. "what we do" and they are
> different things. I would submit that there are some fundamental
> differences between contributing to open source and working in
> the tech industry... and these differences may be significant.
> Maybe one reason is that men find it important to constantly
> prove themselves and contributing to open source is a good
> way to do that; women are more secure and don't need such
> frivolity? (I am NOT saying that this is the case, BTW. My
> point is that there might be reasons NOT due to discouragement)

Perhaps our now, more occasional long email threads that seem to some like 
filibustering are a turn off, and silently drive people away?

Let’s look at what we can do to make it better even if we have untested 
assumptions.

>> 
>> again. I have made a number of suggestions for starting points in this very
>> thread. and have not gone into more detail, because frankly I am exhausted
>> trying to get people to even acknowledge *we have a problem* -- something
>> that is exemplified by your not-so-subtle hand-wringing about "teh social
>> justice warriors" in your last email
> 
> Your last sentence proved my point... :(
>> 
>> (if you're looking for reasons women might not want to contribute to
>> Apache, perhaps this serves as one example...)
>> 
> 
> As does this unfortunately.

Filibustering - I mean it in both the sense of long winded political discussion 
and unauthorized military exhibitions - 19th century and earlier.


> 
>> I want everyone and anyone who wishes to contribute to Apache to
>>> be able to do so, be warmly welcomed, and be acknowledged and rewarded
>>> for their actions and contributions. I think we are all in agreement
>>> here.
>>> 
>> 
>> then why do you dismiss criticism of the systems we've put in place to
>> supposedly work towards those goals? criticism that is sorely needed
>> 
> 
> Again, my point is that the systems are not the issue, but rather the
> implementation of them. If they are broken, we need to fix them. I
> don't dismiss the criticism. I want to understand the criticism.
> 
> I don't expect you, or anyone, to take my claims at face value.
> But nor do I take anyone's claims at face value either...
> 
> We agree with:
>   Is the ASF as diverse as the population? No.
>   ... as the tech industry in NA? No.
>   Would it be good to be more diverse? Yes.
> 
> We seem to disagree with the root causes behind #1 and #2
> and maybe about what "success" would look like for #3.
> But these are not unsurmountable disagreements. I am sure
> we could and can find common ground. Certainly more information
> and data would be very useful!

See my observation about the Incubator. You’ve been involved there.

What do you think?

BTW - Bertrand is leading a website rewrite and that is an opportunity to help 
shape the message and provide information!

Regards,
Dave


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

[jira] [Commented] (COMDEV-307) GSoC - Allura - responsive web pages

[Dave Brondsema (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMDEV-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799334#comment-16799334
 ] 

Dave Brondsema commented on COMDEV-307:
---

Hi [~dilshandilip] I'd recommend first installing Allura and getting it running 
so you can be familiar with it.  Then you could try experimenting with a simple 
page template and see how it works.  Join our dev mailing list at 
[https://lists.apache.org/list.html?d...@allura.apache.org] to ask any 
questions.  It'd be good to do some initial small work with Allura (see the 
contributing section of the docs).

> GSoC - Allura - responsive web pages
> 
>
> Key: COMDEV-307
> URL: https://issues.apache.org/jira/browse/COMDEV-307
> Project: Community Development
>  Issue Type: Improvement
>  Components: GSoC/Mentoring ideas
>Reporter: Dave Brondsema
>Priority: Major
>  Labels: css, gsoc2019, html, javascript, sass, ux
>
> Allura's web frontend should be responsive.  Initial prototyping work has 
> begun using the Foundation framework: 
> [https://foundation.zurb.com/sites/docs/]  More initial work needs to be done 
> to develop a reliable pattern, and then convert existing templates to use 
> Foundation HTML markup and CSS (SCSS, actually) to layout the pages in an 
> intuitive way for all screen sizes.  Interactivity via JS may need to be 
> updated as well.  Some more details are here 
> [https://lists.apache.org/thread.html/f441cef1d288410be5b6c6fc521d62d350ba92df5b4c0e84ea734d5d@%3Cdev.allura.apache.org%3E]
> https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: on "meritocracy"

[Dave Fisher]

Hi Naomi,

Thanks for (re)starting this discussion. I’ve come to agree that there are 
serious problems with the word “meritocracy”. Everyone and every culture brings 
their own ever evolving definition. I brought up the Incubator because 
mentoring new podlings currently includes teaching that the ASF is a 
meritocracy and often pushing these projects into actually having discussions 
about which contributors should be invited to be committers and/or PPMC 
members. They each achieve their own “bar” for this. Some are “higher" and some 
“lower”. The ones that set a higher bar may be projects that will never grow 
enough to be sustainable and diverse enough to withstand the natural attrition 
of the “volunteers” that are currently driving the project.

To me the “non-expiring merit” that should be identified by an Apache Project 
Community is those who show that they “care" and willingly, regularly make even 
small contributions to the community. This can be as “insignificant” (to those 
who set a high bar) as answering user questions with regularity. 

I don’t know if there is a single word for it, but I think we should be looking 
for those who willingly contribute in an Open, Sharing, Diverse, Inclusive, and 
Sustainable way. In many projects there have been moments when a Meritorious, 
High Energy, Driving person has become poisonous to that community and has 
needed to be driven away. This is never a fun process. A sustainable community 
that recognizes small contributions and grows volunteers can survive this. If 
not then the project is headed to the Attic or will be forked.

I agree with Rich that having this discussion with membership will encounter a 
fair amount of pushback (and filibustering in the 19th century sense of the 
word)

Regards,
Dave

> On Mar 22, 2019, at 10:06 AM, Naomi Slater  wrote:
> 
> agreed re "do-ocracy"
> 
> 1) like Patricia points out, like "meritocracy", it presupposes our past
> and future ability implement such a system
> 
> 2) even if we *have* been successful at implementing such a system, is that
> really enough for us, from an ideological perspective? are we not concerned
> with who *isn't* contributing, and why? what we can do about it, etc, etc
> 
> this is why I think it's important to separate this into to components: (a)
> a statement about what we want to achieve that explicitly acknowledges the
> potential for bias and discrimination, and (b) practical
> information/guidance that helps us work towards that
> 
> On Fri, 22 Mar 2019 at 17:59, Rich Bowen  wrote:
> 
>> 
>> 
>> On 3/22/19 3:03 AM, Roman Shaposhnik wrote:
>>> It would be very important to come up with a replacement that is
>>> as effective as what we're trying to replace. Frankly, I don't know
>>> a single candidate.
>> 
>> As discussed elsewhere in the thread, simply coming up with a new word,
>> while potentially helpful in starting conversations, doesn't really
>> address the underlying problem. And each new word (do-ocracy is one that
>> has been proposed, for example) comes with its own set of concerns and
>> baggage.
>> 
>> We have had the "what other word can we use" conversation at least once
>> on this mailing list, and at least one on members, in the last 2 years.
>> Neither conversation resulted in anything actionable.
>> 
>> --
>> 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

Re: on "meritocracy"

[Dave Fisher]

Hi Rich,

I’m not sure if you included the Incubator in your analysis. We have mentions 
of meritoc on six pages along with references to foundation pages and links.

The pages are:

guides/proposal.html
guides/graduation.html
guides/community.html
guides/ppmc.html
index.html
policy/incubation.html

Please provide guidance on changes to the Incubator.

Regards,
Dave

> On Mar 22, 2019, at 8:29 AM, Rich Bowen  wrote:
> 
> 
> 
> On 3/22/19 10:55 AM, Naomi Slater wrote many good and helpful things.
> 
> Narrowing it down to the "action items":
> 
>> there are two issues here:
>> 
>> (1) improving our external communication in a way that communicates our
>> desire to build an inclusive, respectful, safe, and equitable organization
> 
> This is something that we can do immediately, in small incremental
> patches, as we find that content. I have, as mentioned, taken a first
> (incomplete!) step to do this on community.apache.org
> 
> I realized this morning that one of those changes may have stepped on
> Bertrand's toes, since he was the primary driver behind the Maturity
> Model prose, which is used in more than just this one place. We (I?)
> need to connect with Bertrand to ensure that the change doesn't get
> reverted in future iterations of that content.
> 
> Meanwhile, anyone here can start looking through the 150 (ish?) places
> on www.apache.org where the term meritocra(cy|tic) is used, and
> determine whether it's valuable to enhance how that is phrased.
> 
>> (2) actually changing the way that we operate to better work towards those
>> goals
>> 
>> doing (2) is where we will continue to be met with resistance. with people
>> who are upset, offended, or irritated by the work we're trying to do, the
>> things we're saying, and the changes we're trying to make
> 
> To which we should, as the Community Development PMC, push back and
> insist that we're working towards the development of the community, as
> per our charter, and that the changes are NOT about what was done in the
> past, or a slight against who did it, but that they are intended to
> welcome the next generation of our community, and build a strong tomorrow.
> 
> Whatever we have done wrong in the past, I feel like it's really
> important to focus on the future. I mean, it's *useful*, as Naomi has
> said, to understand the past, I don't know about y'all, but all I have
> time for is the future.
> 
> As was illustrated brilliantly when Sharan did the community survey a
> couple of years ago, the people who complained that it was a waste of
> time did not, in the long run, have any right to tell us not to waste
> our time in that way. And good came from it.
> 
> The "small incremental changes" model applies.
> 
> -- 
> 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

Re: Google Season of Docs 2019

[Dave Fisher]

> On Mar 12, 2019, at 7:01 PM, Huxing Zhang  wrote:
> 
> Hi Dave,
> 
> On Wed, Mar 13, 2019 at 2:14 AM Dave Fisher  wrote:
>> 
>> Hi -
>> 
>> Looks pretty cool.
> 
> Yes, all the ASF projects could benefit from it. I think ASF should
> apply it on behalf of all ASF projects, just like how the GSoC work.
> Am I right?

Yes! And the time is pretty quick. I’m hoping a someone over here will 
volunteer to help.

Regards,
Dave


> 
>> 
>> Cc: to Apache Community Development.
>> 
>> Regards,
>> Dave
>> 
>> Sent from my iPhone
>> 
>>> On Mar 12, 2019, at 9:22 AM, Huxing Zhang  wrote:
>>> 
>>> Hi,
>>> 
>>> Google Season of Docs 2019[1] seems to be an interesting project,
>>> which bring open source project and technical writer communities
>>> together, just Like Google summer of code.
>>> 
>>> I think the Dubbo can benefit from the project, especially the English
>>> version of documentation could be improved.
>>> 
>>> How do you think?
>>> 
>>> [1] https://developers.google.com/season-of-docs/docs/timeline
>>> 
>>> --
>>> Best Regards！
>>> Huxing
>> 
> 
> 
> -- 
> Best Regards！
> Huxing
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Google Season of Docs 2019

[Dave Fisher]

Hi -

Looks pretty cool.

Cc: to Apache Community Development.

Regards,
Dave

Sent from my iPhone

> On Mar 12, 2019, at 9:22 AM, Huxing Zhang  wrote:
> 
> Hi,
> 
> Google Season of Docs 2019[1] seems to be an interesting project,
> which bring open source project and technical writer communities
> together, just Like Google summer of code.
> 
> I think the Dubbo can benefit from the project, especially the English
> version of documentation could be improved.
> 
> How do you think?
> 
> [1] https://developers.google.com/season-of-docs/docs/timeline
> 
> -- 
> Best Regards！
> Huxing


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

Re: DOAP futures (ASF project metadata)

[Dave Fisher]

Hi -

> On Mar 6, 2019, at 4:51 AM, Shane Curcuru  wrote:
> 
> Bertrand Delacretaz wrote on 3/5/19 7:23 AM:
>> Hi,
>> 
>> On Tue, Mar 5, 2019 at 1:16 PM Mark Cox  wrote:
>>> ... So before investing too more time into this, I wanted to find out if
>>> there's been any real attempt or plan or investigation to replace the DOAP
>>> files within ASF with something else
> ...snip...
>> It might take some initial effort to consolidate that data and fix the
>> software that uses it but I think it's well worth it. Considering that
>> this is infrastructure related, we might ask for funding for this
>> initial cleanup task as I'm not sure we'll get there with volunteer
>> energy only.
> 
> Indeed, centralizing project (including podling) metadata - somehow! -
> is a real need that we've never been able to meet.  I also support
> finding funding for this to task infra to work on it (which is a topic
> for other lists, but it's important to note it here).

I’m currently working on the podling clutch related metadata from ground truth.

Podlings.xml is a key part of this and is currently hand edited. An editing 
error this morning caused Whimsy roster pages to fail. I was able to fix this 
quickly and the new podling caused new error states in the incubator clutch 
process which I fixed.

My goal with the clutch is multiple.

(1) Improve Incubator workflows to better inform podling’s about their state 
wrt graduating to become an Apache TLP.

(2) Improve the process so that all incubator state is found in the ground 
truth and from adaptation to a decade old reporting structure. For example of 
the 51 podlings last week. 50 use gitbox yet Git was not really accommodated. 
Gitbox.apache.org/repositories.json provides ground truth on all Apache git 
repositories.

I would certainly like to be involved …

Regards,
Dave

> 
> Key design criteria:
> 
> - Easy to maintain the whole system.
> 
> - Easy to consume for all users - whimsy especially (since other places
> rely on that), the www.a.o website, *plus* external consumers who might
> want to scrape our project universe.
> 
> - Easy for projects to update.  In particular, having Maven,
> Cocoon/Forrest, GitHub plugins to auto-generate needed data is key; we
> can't ask all projects with existing widely-used tooling to have to add
> unusual steps to their release processes.

As much data as possible should be found in the state of our systems.
For example we should be able to create a download json for a release by 
examining the svn for dist.apache.org <http://dist.apache.org/>.

> 
> Presuming board/ops/infra make this a real project (i.e. funding and
> timeline), where should the design discussion happen?

Regards,
Dave
> 
> -- 
> 
> - Shane
>  Director & Member
>  The Apache Software Foundation
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

[jira] [Commented] (COMDEV-307) GSoC - Allura - responsive web pages

[Dave Brondsema (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMDEV-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782498#comment-16782498
 ] 

Dave Brondsema commented on COMDEV-307:
---

[~nayanagamuhandiram] you should join the dev mailing list at 
[https://lists.apache.org/list.html?d...@allura.apache.org] and introduce 
yourself.  That's the best place to ask questions about Allura.  I would 
recommend first installing Allura and getting it running so you can be familiar 
with it.  Then you could try experimenting with a simple page template and see 
how it works.

> GSoC - Allura - responsive web pages
> 
>
> Key: COMDEV-307
> URL: https://issues.apache.org/jira/browse/COMDEV-307
> Project: Community Development
>  Issue Type: Improvement
>  Components: GSoC/Mentoring ideas
>Reporter: Dave Brondsema
>Priority: Major
>  Labels: css, gsoc2019, html, javascript, sass, ux
>
> Allura's web frontend should be responsive.  Initial prototyping work has 
> begun using the Foundation framework: 
> [https://foundation.zurb.com/sites/docs/]  More initial work needs to be done 
> to develop a reliable pattern, and then convert existing templates to use 
> Foundation HTML markup and CSS (SCSS, actually) to layout the pages in an 
> intuitive way for all screen sizes.  Interactivity via JS may need to be 
> updated as well.  Some more details are here 
> [https://lists.apache.org/thread.html/f441cef1d288410be5b6c6fc521d62d350ba92df5b4c0e84ea734d5d@%3Cdev.allura.apache.org%3E]
> https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (COMDEV-306) GSoC - Allura - Convert to python 3

[Dave Brondsema (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMDEV-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782126#comment-16782126
 ] 

Dave Brondsema commented on COMDEV-306:
---

[~Abhism] you should join the dev mailing list at 
[https://lists.apache.org/list.html?d...@allura.apache.org] and introduce 
yourself.  That's the best place to ask questions about Allura.  I would 
recommend first installing Allura and getting it running so you can be familiar 
with it.  Then you could try upgrading one dependency from requirements.txt at 
a time, and see if everything works and tests pass still.  That'd be a good 
starting task to try.

> GSoC - Allura - Convert to python 3
> ---
>
> Key: COMDEV-306
> URL: https://issues.apache.org/jira/browse/COMDEV-306
> Project: Community Development
>  Issue Type: Improvement
>  Components: GSoC/Mentoring ideas
>Reporter: Dave Brondsema
>Priority: Major
>  Labels: gsoc2019, python
>
> Allura is a large mature codebase, and relies on many dependencies.  The path 
> to python 3 will have many steps, but we need to start working on it.  GSOC 
> work would include familiarizing with porting guides like 
> [https://docs.python.org/3/howto/pyporting.html] and 
> [https://portingguide.readthedocs.io/en/latest/] and 
> [http://python3porting.com/] and then working through steps like:
>  * upgrading dependencies, and updating code & tests to match
>  * removing or replacing dependencies where needed, and updating code
>  * running futurize or modernize, manual code changes where needed, cleanup, 
> etc
>  * testing
>  * documentation updates
>  * Docker updates
>  * more, probably :)
> https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (COMDEV-308) GSoC - Allura - importers / sync for Bitbucket and Gitlab

[Dave Brondsema (JIRA)]

Dave Brondsema created COMDEV-308:
-

 Summary: GSoC - Allura - importers / sync for Bitbucket and Gitlab
 Key: COMDEV-308
 URL: https://issues.apache.org/jira/browse/COMDEV-308
 Project: Community Development
  Issue Type: Improvement
  Components: GSoC/Mentoring ideas
Reporter: Dave Brondsema


Allura has a solid framework for doing imports, and has implemented this for 
services like GitHub, Google Code and Trac.  It covers aspects from Git/Hg/SVN 
to tickets and wikis.

It would be great to enhance this to support importing & converting data from 
Bitbucket and Gitlab.  The level of integration & conversion may vary depending 
on the format and structure of the services.

Beyond that, related improvements could be made in supporting ongoing 
synchronization of Git/Hg/SVN repositories (not just a one-time import).  Or 
importers for JIRA, or improving importing of Allura's own formats.

Everything in the ForgeImporters directory is our existing import system.  The 
forgeimporters/base.py file has several base classes that provide common 
functionality for all importers to use.  In the subdirectories "forge" "github" 
and "google" there are specific importers that can be good examples to 
reference.  Importers can also be external packages, see these repos as more 
examples: [https://sourceforge.net/p/mediawikiimporter/git/ci/master/tree/] and 
[https://sourceforge.net/p/tracwikiimporter/git/ci/master/tree/]

https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (COMDEV-307) GSoC - Allura - responsive web pages

[Dave Brondsema (JIRA)]

Dave Brondsema created COMDEV-307:
-

 Summary: GSoC - Allura - responsive web pages
 Key: COMDEV-307
 URL: https://issues.apache.org/jira/browse/COMDEV-307
 Project: Community Development
  Issue Type: Improvement
  Components: GSoC/Mentoring ideas
Reporter: Dave Brondsema


Allura's web frontend should be responsive.  Initial prototyping work has begun 
using the Foundation framework: [https://foundation.zurb.com/sites/docs/]  More 
initial work needs to be done to develop a reliable pattern, and then convert 
existing templates to use Foundation HTML markup and CSS (SCSS, actually) to 
layout the pages in an intuitive way for all screen sizes.  Interactivity via 
JS may need to be updated as well.  Some more details are here 
[https://lists.apache.org/thread.html/f441cef1d288410be5b6c6fc521d62d350ba92df5b4c0e84ea734d5d@%3Cdev.allura.apache.org%3E]

https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (COMDEV-306) GSoC - Allura - Convert to python 3

[Dave Brondsema (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COMDEV-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dave Brondsema updated COMDEV-306:
--
Component/s: GSoC/Mentoring ideas

> GSoC - Allura - Convert to python 3
> ---
>
> Key: COMDEV-306
> URL: https://issues.apache.org/jira/browse/COMDEV-306
> Project: Community Development
>  Issue Type: Improvement
>  Components: GSoC/Mentoring ideas
>Reporter: Dave Brondsema
>Priority: Major
>  Labels: gsoc2019, python
>
> Allura is a large mature codebase, and relies on many dependencies.  The path 
> to python 3 will have many steps, but we need to start working on it.  GSOC 
> work would include familiarizing with porting guides like 
> [https://docs.python.org/3/howto/pyporting.html] and 
> [https://portingguide.readthedocs.io/en/latest/] and 
> [http://python3porting.com/] and then working through steps like:
>  * upgrading dependencies, and updating code & tests to match
>  * removing or replacing dependencies where needed, and updating code
>  * running futurize or modernize, manual code changes where needed, cleanup, 
> etc
>  * testing
>  * documentation updates
>  * Docker updates
>  * more, probably :)
> https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (COMDEV-306) GSoC - Allura - Convert to python 3

[Dave Brondsema (JIRA)]

Dave Brondsema created COMDEV-306:
-

 Summary: GSoC - Allura - Convert to python 3
 Key: COMDEV-306
 URL: https://issues.apache.org/jira/browse/COMDEV-306
 Project: Community Development
  Issue Type: Improvement
Reporter: Dave Brondsema


Allura is a large mature codebase, and relies on many dependencies.  The path 
to python 3 will have many steps, but we need to start working on it.  GSOC 
work would include familiarizing with porting guides like 
[https://docs.python.org/3/howto/pyporting.html] and 
[https://portingguide.readthedocs.io/en/latest/] and 
[http://python3porting.com/] and then working through steps like:
 * upgrading dependencies, and updating code & tests to match
 * removing or replacing dependencies where needed, and updating code
 * running futurize or modernize, manual code changes where needed, cleanup, etc
 * testing
 * documentation updates
 * Docker updates
 * more, probably :)

https://allura.apache.org/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Contributing an updated slide deck

[Dave Fisher]

Cool. Some comments.

Side 5

PMC Chairs are Vice Presidents of the project and officers of the Foundation.

Slide 8

In my opinion, Vendor Neutrality is either a 4th Pillar, the Foundation, or an 
adjunct to the “How It Works”. I’m not sure which metaphor is best, but the 
topic should be covered.

Slide 12

In the Incubator we like to guide podlings to delay users@ until there is a 
proven need. Reason is that having just dev@ can be important to all interested 
devs and new users to their experience with the code and developing community.

Also, you don’t mention commits@ where most project direct various code changes 
and other logging. The usual impetus for that that dev@ is getting hammered 
with these emails. That said the PMC is expected to subscribe to and follow a 
commits@ mailing list.

Slide 13 

If the PMC Chair is negligent in reporting duties to the Board then the other 
PMC members can step in and submit the quarterly board report. Beyond the duty 
to the foundation as an officer PMC Chairs have no more responsibilities or 
rights than the other PMC members. In a sense their duties are more secretarial 
than leadership. The ASF goes for a flat hierarchy as much as feasible.

ASF Members do not vote on new Incubator podlings. It works as so (currently) - 
any member can join the Incubator PMC. The Incubator PMC can also elect PMC 
members from people that they have identified as knowledgeable on the Apache 
Way (and likely candidates for Apache Membership at the next annual meeting 
(recently in March)).

Slide 16

You miss voting on new committers and PMC members which is technically your 
“Majority Approval” but culturally is better as “Consensus Approval”. I think 
that the distinction between the two is not so much as you describe. It is more 
that “Consensus” is preferred, but sometimes “Majority” is what you get. I 
think that others will want to debate this point.

Slide 20
Should the escalation point be the code of conduct? That does offer a concrete 
ML to escalate towards.

Slide 21
I think your description of a PMC member applies to Committers as well. For PMC 
members I would discuss binding votes on releases, approving new committers and 
PMC members and managing the project brand. I’m sure that lis tis incomplete.

Sorry, this is way more wordy than I intended. Take it as you wish.

Regards,
Dave


> On Jan 21, 2019, at 8:20 PM, Aizhamal Nurmamat kyzy 
>  wrote:
> 
> Hello everyone,
> 
> I recently shared a slide deck with an introduction to "The Apache Way" in
> this mailing list. I've got some very valuable feedback from community
> members, and I have incorporated some into the slides. The updated deck is
> here:
> 
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> <https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p>
> 
> The material is intended to be used by anyone for their presentations. I am
> not a committer, but I was wondering if it would be of decent enough
> quality to be included in the slides section[2]? If it is, is there a
> committer in this group that could help me do that change?
> 
> Thanks to everyone for your help and feedback!
> -A.
> 
> [1]
> https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p
> <https://docs.google.com/presentation/d/183nXPAxpJymQBOYOt1FnFaahRcQskIvOyIvHRC6UAnE/edit#slide=id.p>
> [2] https://community.apache.org/speakers/slides.html
> 
> --


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

Re: comdev VMs need consolidation

[Dave Fisher]

+1. Comdev is not like other projects.

Sent from my iPhone

> On Jan 2, 2019, at 6:37 PM, Daniel Gruno  wrote:
> 
>> On 1/3/19 3:31 AM, Chris Lambertus wrote:
>> Hi Comdev folks,
>> comdev currently has three VMs :
>> projects-vm2 (projects, reporter)
>> comdev-vm (helpwanted)
>> community-vm (community.zones)
>> This is way beyond what we normally provide projects, and they are taking up 
>> precious resources in our most impacted colos. These need to be consolidated 
>> down to a single VM. I’d like to work with someone on comdev to migrate 
>> everything over to the new(ish) projects-vm2 box. Who is willing to help me 
>> with this?
> 
> Alternately, and this is just my thinking, since ComDev lives through 
> services and VMs more than traditional code projects, it might help if we get 
> a dedicated budget from the board for this, even if it's just a tiny 
> $600/year one (an example that would cover the hardware for the 
> above-mentioned three VMs). Some consolidation could still happen, but it 
> would separate things from infra's own resource pool a bit.
> 
> WDYT?
> 
> With regards,
> Daniel.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Feedback requested: New committer invitation template

[Dave Fisher]

Hi Craig,

This is the perfect new guidance.

(1) I think that similar process needs to be used by Incubator Mentors for 
Initial PPMC Members.

(2) I assume you will send to pmcs@ once the new guidance is confirmed. I don’t 
have specific edits in mind, but others no doubt may.

(I wonder if writing this email can be automated on whimsy roster pages?)

Best Regards,
Dave

Sent from my iPhone

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


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

Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)

[Dave Fisher]

> On Nov 5, 2018, at 8:35 AM, Christopher  wrote:
> 
> On Mon, Nov 5, 2018 at 3:49 AM Bertrand Delacretaz
>  wrote:
>> 
>> Hi,
>> 
>> On Fri, Nov 2, 2018 at 7:02 PM Christopher  wrote:
>>> ...it would be a mistake if ASF were to try to impose a more spammy
>>> workflow to dev@ onto every PMC, as a requirement...
>> 
>> FWIW I didn't suggest imposing anything like that - my only concern is
>> that it should be possible to follow the action of any of our projects
>> just by subscribing to their dev list.
>> 
> 
> That problem is not specific to GitHub. Are you equally concerned
> about JIRA activity going to notifications@ and SVN activity going to
> commits@ (especially with commit-then-review) ?
> 
>> Watching GitHub repositories is fine but some of our projects have
>> many repositories and just finding out which ones to watch depending
>> on what one's interested in can be problematic, IMO.
>> 
>> -Bertrand
>> 
> 
> A weekly summary of active issues/PRs for all of that project's repos,
> posted to the dev@ list might be useful, but it could also be too
> large to be useful.
> 
> It might also be useful to contributors to have an automated monthly
> email from INFRA to remind the project of all INFRA resources used by
> the project, such as mailing lists, git repos, git mirrors, reserved
> svn paths, issue trackers, Maven staging profiles, etc. That way,
> newcomers can be made aware of all resources in use by the project (in
> case they missed that info on the project website), so they can have
> an opportunity to subscribe to them as they choose, or ask questions
> about them on the dev@ list.

The Whimsy Roster for a PMC has most of this information. It might be nice to 
have a public version of the project information.

Links
Mailing Lists
Committers
PMC
Prior Reports

Regards,
Dave


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