AW: [WG: Sharpeners] Proposed - Sharpeners

[Christofer Dutz]

Hi Rich,

I love every line of it … the only thing I would possibly “fine tune” in the 
text, would be to be a bit more explicit:
“You must not already be a member of the PMC.” -> “You must not already be a 
member of the PMC that you wish to join as Sharpener.” Cause I was a bit 
confused which of the many PMCs involved you were talking about.

And: As we voted on that every Member can request to join the ComDev PMC, maybe 
simply add to the proposal, that if you want to be a Sharpener, that you simply 
ask to join the ComDev PMC.

Other than that … count me in.

Chris

Von: MJ Foulks 
Datum: Freitag, 9. Februar 2024 um 17:02
An: dev@community.apache.org 
Betreff: Re: [WG: Sharpeners] Proposed - Sharpeners
This is another great idea.

You mentioned objections along the lines of "who are you to tell me what to
do?"  Most volunteers do better with some direction, rather than being told
"just submit a PR"  or "just contribute."  Most volunteers, especially new
volunteers such as myself, find that lack of direction frustrating.  Lack
of direction will lead to less active volunteers doing less work.

 Sharpeners can help provide direction without it having to come from a
position of authority.  I do agree that the Sharpener (even if a leader of
the WG) should not have any higher authority than others. However, their
position as a Sharpener should be recognized and respected, and their
advice taken with their elevated role in mind.  They are peers, but they
are peers with a more broad view and more experience in their skill set.
Advice can be taken or left, but a Sharpener's advice should, ideally, be
given more thought and consideration.

--MJ Foulks

On Fri, Feb 9, 2024 at 10:33 AM Rich Bowen  wrote:

>
> > On Feb 9, 2024, at 10:18 AM, Daniel Gruno  wrote:
> >
> > I like this proposal a lot, and would be happy to sharpen some pencil
> mahogany cases, if allowed (unless this pun was so bad you have to decline
> my offer).
> >
> > I do have one question, which is where this ...
> report bit would go, would that be entered into the comdev board report?
>
>
> I think that’s a detail for the WG to work out, in conjunction with the
> ComDev PMC and Chair, but my vision is that if/when any of these WGs start
> producing actual work, we would add a WG section to the ComDev report, and
> report on that work there. It’s an interesting question, though, because it
> might imply that the WG lead must be a ComDev PMC member, so that they
> *can* make these  comments. Or perhaps they just communicate with
> the PMC Chair directly? I’m not sure. We cannot violate PMC confidentially,
> whatever we do.
>
> *Ideally*, the comments/advice of an effective sharpener would also
> influence things showing up in the individual PMC’s report, too, but there
> will be cases where the Sharpener’s comments are about red flags in the
> project, and they will be asking the board to look into it, escalate, or
> whatever, since the Sharpener themself has no authority to do anything but
> advise.
>
>

AW: Nearby ASF people, or volunteers page?

[Christofer Dutz]

Actually my computer is pretty hard … I notice that every time I punch it cause 
it’s not doing what I want it to ;-)

Chris


Von: Bertrand Delacretaz 
Datum: Montag, 27. November 2023 um 12:36
An: dev@community.apache.org 
Betreff: Re: Nearby ASF people, or volunteers page?
On Mon, Nov 27, 2023 at 12:34 PM Roman Shaposhnik  wrote:
> ...This would work for me, but I'd really love to have a map
> visualisation view as well
> (this should't be too hard, right? ;-))..

Nothing's hard when you have a computer, patches welcome I guess ;-)

-Bertrand

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

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

[Christofer Dutz]

Hi Roman,

Well, I guess stuff like the content from Apache-legal wouldn’t be what I would 
feel comfortable with having auto-translated.
But for most other stuff, I could imagine that storing the original and then 
maybe using the openAI API to have it translated to English and then storing 
that alongside on the incoming part, would be one option.
Then I could imagine that there must be some sort of JS plugin, we could 
integrate into our websites that checks if there’s an original in that language 
or to use the same API to dynamically have it translated.

But I understand that currently this is sort of a theoretic question.

I would doubt MS/OpenAI would appreciate us asking up to 2 questions for 
everything that happens at the ASF:

  *   Is this content English?
  *   Please translate this content to English

Also could I imagine that this service would not be available to everyone and 
in all countries, so probably for the ad-hoc translations a pluggable mechanism 
probably would be required.

But I think it would be worth digging deeper, if there’s a general consent 
here, that something like that would make sense.

Chris


Von: Roman Shaposhnik 
Datum: Donnerstag, 26. Oktober 2023 um 13:05
An: dev@community.apache.org 
Betreff: Re: Helping to welcome non-english communities by questioning our 
rules?
On Thu, Oct 26, 2023 at 10:42 AM Christofer Dutz
 wrote:
>
> Hi all,
>
> as some of you might know, I recently joined a company where most employees 
> are native Chinese speakers.
> I was looking forward to this for the reason of gaining more insight into how 
> these communities work and was hoping to gain some actionable things to help 
> make the ASF more welcoming to these communities.
>
> Yes: Many of us say: English is the most spoken and understood language on 
> the planet.
> However even if someone might understand English and might be able to write 
> English, they still might not feel comfortable doing so.
> In the PLC4X project we have one person who stated that on multiple occasions 
> and he’s a valuable part of the community.
>
> It seems that our way of writing English emails, even if accessible to 
> communities in China, still it causes them to build up parallel structures:
>
>   *   WeChat Groups
>   *   Workspaces using tools like Lark/Feishu
>
> I was always trying to convince them to come and have discussions on 
> mailing-lists but have generally failed to do so.
>
> Now after starting to work at Timecho, I got used to using their chat tool 
> (Feishu) … it’s sort of like Teams combined with Office 365.
> But the feature that struck me most, was the ability that I could select any 
> channel and enable the “Translation assistant”. Here I could select which 
> language I want to read the discussions in, and I can even have the assistant 
> auto-translate everything to Chinese. This way I can communicate with my 
> colleagues as if I was communicating with native English speakers. It’s been 
> nothing but amazing to see how easy it is to simply ignore language barriers 
> and focus on the task at hand and not having to deal with writing in a 
> non-native language (Well … I think I would be 100% lost, if someone asked me 
> to write in Chinese ;-) )
>
> This got me thinking:
> We have this rule: If it didn’t happen on the list, it didn’t happen (Don’t 
> even know if it’s really written down somewhere or if it’s just a common 
> mantra).
> But I think this is just one instance of a solution to the problem of us 
> wanting to have every decision documented and archived and searchable, so 
> everyone can participate and later search for reasons why a project did what 
> they did.
> So … what if we question this rule.
> I was thinking of if we couldn’t achieve what the rule wanted, by introducing 
> a new solution into the picture.
> What if we had a global storage for everything that happens in a project?
> Every input to the project is stored in this system. This input could be in 
> any language.
> If we had a sponsor to allow auto-translating things to English (I am sure 
> there are services out there able to do that)
> A translated English version could be stored alongside the original.
> Now every system we use, could have plugins to send to this central system: 
> Email, GitHub, Jira, Slack, WeChat, …
> If someone could now use this system to follow everything that a project is 
> doing, possibly using the translation API to have things converted into the 
> language he can understand.
>
> I think (except for the translation service), we should have everything we 
> need inside the foundation.
>
> What do you folks think?

Yes, and... ;-)

...I've been thinking along the same lines given that I have recently
helped OpenAtom Foundation get to a point where they have native
tra

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

[Christofer Dutz]

Hi all,

as some of you might know, I recently joined a company where most employees are 
native Chinese speakers.
I was looking forward to this for the reason of gaining more insight into how 
these communities work and was hoping to gain some actionable things to help 
make the ASF more welcoming to these communities.

Yes: Many of us say: English is the most spoken and understood language on the 
planet.
However even if someone might understand English and might be able to write 
English, they still might not feel comfortable doing so.
In the PLC4X project we have one person who stated that on multiple occasions 
and he’s a valuable part of the community.

It seems that our way of writing English emails, even if accessible to 
communities in China, still it causes them to build up parallel structures:

  *   WeChat Groups
  *   Workspaces using tools like Lark/Feishu

I was always trying to convince them to come and have discussions on 
mailing-lists but have generally failed to do so.

Now after starting to work at Timecho, I got used to using their chat tool 
(Feishu) … it’s sort of like Teams combined with Office 365.
But the feature that struck me most, was the ability that I could select any 
channel and enable the “Translation assistant”. Here I could select which 
language I want to read the discussions in, and I can even have the assistant 
auto-translate everything to Chinese. This way I can communicate with my 
colleagues as if I was communicating with native English speakers. It’s been 
nothing but amazing to see how easy it is to simply ignore language barriers 
and focus on the task at hand and not having to deal with writing in a 
non-native language (Well … I think I would be 100% lost, if someone asked me 
to write in Chinese ;-) )

This got me thinking:
We have this rule: If it didn’t happen on the list, it didn’t happen (Don’t 
even know if it’s really written down somewhere or if it’s just a common 
mantra).
But I think this is just one instance of a solution to the problem of us 
wanting to have every decision documented and archived and searchable, so 
everyone can participate and later search for reasons why a project did what 
they did.
So … what if we question this rule.
I was thinking of if we couldn’t achieve what the rule wanted, by introducing a 
new solution into the picture.
What if we had a global storage for everything that happens in a project?
Every input to the project is stored in this system. This input could be in any 
language.
If we had a sponsor to allow auto-translating things to English (I am sure 
there are services out there able to do that)
A translated English version could be stored alongside the original.
Now every system we use, could have plugins to send to this central system: 
Email, GitHub, Jira, Slack, WeChat, …
If someone could now use this system to follow everything that a project is 
doing, possibly using the translation API to have things converted into the 
language he can understand.

I think (except for the translation service), we should have everything we need 
inside the foundation.

What do you folks think?

Chris

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

[Christofer Dutz]

Ok … changes have been merged … now let’s see ;-)

Chris

Von: Christofer Dutz 
Datum: Samstag, 30. September 2023 um 08:39
An: dev@community.apache.org 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
Well it wouldn't be you, who's getting the beer... You would need ask sebb to 
share that beer with you ;-)

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Christopher 
Sent: Saturday, September 30, 2023 1:57:02 AM
To: ComDev 
Subject: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?

Loophole question: can we start a campaign to complain just to get free
beer?

On Fri, Sep 29, 2023, 15:25 Craig Russell  wrote:

> I thought that a few folks responded to sebb earlier in the thread.
> Repeating an earlier post does not make it a new post.
>
> Changing defaults will not affect people who have changed their own
> project settings. And if they are happy with the defaults to the extent
> that they complain about the defaults changing for the better, I will split
> the bar tab with you
>
> Craig
>
> > On Sep 29, 2023, at 09:09, Christofer Dutz 
> wrote:
> >
> > As it was pointed out that nobody responded to this, let me do so:
> >
> > We have provided docs for quite some time … nothing really has changed
> as many projects are on a steep decline on using their lists.
> > These proposes changes have seen a very dominant support by most people
> who expressed their thoughts here.  You are currently the only person
> actively objecting.
> >
> > We are trying to improve things.
> > We are also not forcing anything on anyone … whoever wants things to
> stay the way they were, we provided all the information upfront to how they
> can keep things the way they were.
> >
> > Let’s make a one-sided bet: if there are more people complaining about
> the change after it happened than are expressing to be happy with them,
> I’ll invite you to a beer?
> >
> > Chris
> >
> >
> >
> > Von: sebb 
> > Datum: Freitag, 4. August 2023 um 11:21
> > An: dev@community.apache.org 
> > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> > NAK - I don't think the defaults should be changed; instead provide
> > docs on how to do so
> > Don't force projects to change if they don't want to
> >
> > On Wed, 2 Aug 2023 at 07:46, Christofer Dutz 
> wrote:
> >>
> >> Well,
> >>
> >> stating the obvious, I’ll add my +1 ;-)
> >>
> >> And yes Craig, I said the defaults … if you have explicitly configured
> your .asf.yaml subjects, they are left unchanged.
> >>
> >> Chris
> >>
> >>
> >> Von: Richard Zowalla 
> >> Datum: Mittwoch, 2. August 2023 um 08:10
> >> An: dev@community.apache.org 
> >> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> >> +1
> >>
> >> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk  >:
> >>> +1
> >>>
> >>> On Wed, Aug 2, 2023 at 2:15 AM Craig Russell 
> wrote:
> >>>>
> >>>> Hi Christofer,
> >>>>
> >>>> As long as projects with their own settings can continue to use them,
> I'm
> >>>>
> >>>> +1
> >>>>
> >>>> to change the defaults for all projects. If the projects don't like
> being able to use their lists again, they can always go back to what they
> had before.
> >>>>
> >>>> Thanks,
> >>>> Craig
> >>>>
> >>>>> On Aug 1, 2023, at 05:16, Christofer Dutz 
> wrote:
> >>>>>
> >>>>> Starting a new thread as the last one sort of dried up and didn’t
> quite form anything actionable.
> >>>>>
> >>>>> Being subscribed to many of our mailing-lists and most recently
> looking into every project, dev-lists when reviewing board reports, I have
> seen many of our lists literally being rendered useless.
> >>>>>
> >>>>> Useless, because it’s almost impossible to follow these lists, as a
> large percentage of the emails are:
> >>>>>
> >>>>> *   Generated emails and the way they are currently generated makes
> it impossible for email clients to correctly display them as threads.
> >>>>> *   Contain so much redundant information, that the act

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

[Christofer Dutz]

Well it wouldn't be you, who's getting the beer... You would need ask sebb to 
share that beer with you ;-)

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Christopher 
Sent: Saturday, September 30, 2023 1:57:02 AM
To: ComDev 
Subject: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?

Loophole question: can we start a campaign to complain just to get free
beer?

On Fri, Sep 29, 2023, 15:25 Craig Russell  wrote:

> I thought that a few folks responded to sebb earlier in the thread.
> Repeating an earlier post does not make it a new post.
>
> Changing defaults will not affect people who have changed their own
> project settings. And if they are happy with the defaults to the extent
> that they complain about the defaults changing for the better, I will split
> the bar tab with you
>
> Craig
>
> > On Sep 29, 2023, at 09:09, Christofer Dutz 
> wrote:
> >
> > As it was pointed out that nobody responded to this, let me do so:
> >
> > We have provided docs for quite some time … nothing really has changed
> as many projects are on a steep decline on using their lists.
> > These proposes changes have seen a very dominant support by most people
> who expressed their thoughts here.  You are currently the only person
> actively objecting.
> >
> > We are trying to improve things.
> > We are also not forcing anything on anyone … whoever wants things to
> stay the way they were, we provided all the information upfront to how they
> can keep things the way they were.
> >
> > Let’s make a one-sided bet: if there are more people complaining about
> the change after it happened than are expressing to be happy with them,
> I’ll invite you to a beer?
> >
> > Chris
> >
> >
> >
> > Von: sebb 
> > Datum: Freitag, 4. August 2023 um 11:21
> > An: dev@community.apache.org 
> > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> > NAK - I don't think the defaults should be changed; instead provide
> > docs on how to do so
> > Don't force projects to change if they don't want to
> >
> > On Wed, 2 Aug 2023 at 07:46, Christofer Dutz 
> wrote:
> >>
> >> Well,
> >>
> >> stating the obvious, I’ll add my +1 ;-)
> >>
> >> And yes Craig, I said the defaults … if you have explicitly configured
> your .asf.yaml subjects, they are left unchanged.
> >>
> >> Chris
> >>
> >>
> >> Von: Richard Zowalla 
> >> Datum: Mittwoch, 2. August 2023 um 08:10
> >> An: dev@community.apache.org 
> >> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> >> +1
> >>
> >> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk  >:
> >>> +1
> >>>
> >>> On Wed, Aug 2, 2023 at 2:15 AM Craig Russell 
> wrote:
> >>>>
> >>>> Hi Christofer,
> >>>>
> >>>> As long as projects with their own settings can continue to use them,
> I'm
> >>>>
> >>>> +1
> >>>>
> >>>> to change the defaults for all projects. If the projects don't like
> being able to use their lists again, they can always go back to what they
> had before.
> >>>>
> >>>> Thanks,
> >>>> Craig
> >>>>
> >>>>> On Aug 1, 2023, at 05:16, Christofer Dutz 
> wrote:
> >>>>>
> >>>>> Starting a new thread as the last one sort of dried up and didn’t
> quite form anything actionable.
> >>>>>
> >>>>> Being subscribed to many of our mailing-lists and most recently
> looking into every project, dev-lists when reviewing board reports, I have
> seen many of our lists literally being rendered useless.
> >>>>>
> >>>>> Useless, because it’s almost impossible to follow these lists, as a
> large percentage of the emails are:
> >>>>>
> >>>>> *   Generated emails and the way they are currently generated makes
> it impossible for email clients to correctly display them as threads.
> >>>>> *   Contain so much redundant information, that the actual start of
> the header that I’m interested in reading is usually not readable on mobile
> phones.
> >>>>> *   Most discussions have been moved away from the lists
> (notifications@, commits@), having left over only skeletons in which
> every n

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

[Christofer Dutz]

As it was pointed out that nobody responded to this, let me do so:

We have provided docs for quite some time … nothing really has changed as many 
projects are on a steep decline on using their lists.
These proposes changes have seen a very dominant support by most people who 
expressed their thoughts here.  You are currently the only person actively 
objecting.

We are trying to improve things.
We are also not forcing anything on anyone … whoever wants things to stay the 
way they were, we provided all the information upfront to how they can keep 
things the way they were.

Let’s make a one-sided bet: if there are more people complaining about the 
change after it happened than are expressing to be happy with them, I’ll invite 
you to a beer?

Chris



Von: sebb 
Datum: Freitag, 4. August 2023 um 11:21
An: dev@community.apache.org 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
NAK - I don't think the defaults should be changed; instead provide
docs on how to do so
Don't force projects to change if they don't want to

On Wed, 2 Aug 2023 at 07:46, Christofer Dutz  wrote:
>
> Well,
>
> stating the obvious, I’ll add my +1 ;-)
>
> And yes Craig, I said the defaults … if you have explicitly configured your 
> .asf.yaml subjects, they are left unchanged.
>
> Chris
>
>
> Von: Richard Zowalla 
> Datum: Mittwoch, 2. August 2023 um 08:10
> An: dev@community.apache.org 
> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
> generate GitHub integration email subjecs?
> +1
>
> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk :
> >+1
> >
> >On Wed, Aug 2, 2023 at 2:15 AM Craig Russell  wrote:
> >>
> >> Hi Christofer,
> >>
> >> As long as projects with their own settings can continue to use them, I'm
> >>
> >> +1
> >>
> >> to change the defaults for all projects. If the projects don't like being 
> >> able to use their lists again, they can always go back to what they had 
> >> before.
> >>
> >> Thanks,
> >> Craig
> >>
> >> > On Aug 1, 2023, at 05:16, Christofer Dutz  
> >> > wrote:
> >> >
> >> > Starting a new thread as the last one sort of dried up and didn’t quite 
> >> > form anything actionable.
> >> >
> >> > Being subscribed to many of our mailing-lists and most recently looking 
> >> > into every project, dev-lists when reviewing board reports, I have seen 
> >> > many of our lists literally being rendered useless.
> >> >
> >> > Useless, because it’s almost impossible to follow these lists, as a 
> >> > large percentage of the emails are:
> >> >
> >> >  *   Generated emails and the way they are currently generated makes it 
> >> > impossible for email clients to correctly display them as threads.
> >> >  *   Contain so much redundant information, that the actual start of the 
> >> > header that I’m interested in reading is usually not readable on mobile 
> >> > phones.
> >> >  *   Most discussions have been moved away from the lists 
> >> > (notifications@, commits@), having left over only skeletons in which 
> >> > every now and then a vote is being handled.
> >> >
> >> > My proposal is to change the default settings for auto-generated GitHub 
> >> > emails for all projects (not just the new ones) to be a much more 
> >> > condensed version.
> >> >
> >> > With these changes, all existing lists, that haven’t manually configured 
> >> > the format of the emails, instantly get readable lists again.
> >> >
> >> > Some would argue that there might be projects that could object these 
> >> > changes, but I would on the other hand bet that more projects would be 
> >> > in favor of such a change than not.
> >> > Those who don’t want a change, can simply go back to the old format, by 
> >> > specifying it in one commit for which we can even provide a default 
> >> > .asf.yaml snippet.
> >> >
> >> > Some people expressed the wish to have longer prefixes, such as 
> >> > “[ISSUE]”, “[PULL-REQUEST]” or “[DISCUSSION]” however do these not add 
> >> > much information to the email that “[I]”, “[PR]” and “[D]” don’t and the 
> >> > shorter version allows displaying more of the subject on mobile email 
> >> > clients.
> >> >
> >> > Here’s an example of a project list before the changes:
> >> > https://lists.apache.o

AW: Releasing with lazy consensus

[Christofer Dutz]

Yeah,

thanks for bringing this up … this is actually something I brought up in the 
last board meeting.
I also think it’s not ok to release stuff like parent poms with lazy consensus 
and was currently following up with ASF Legal on that matter.

Just because some projects might be doing it, doesn’t mean it’s ok … possible 
outcome of this might be that this practice will explicitly be forbidden.

My personal reasoning for this:

  *   With a parent pom, I can
 *   Manage dependencies to get in vulnerable versions
 *   Include additional dependencies
 *   Re-Configure plugins configuration
 *   Add plugin executions that might do bad stuff
So I think especially for parent poms we should pay extra attention.

Chris





Von: Jarek Potiuk 
Datum: Freitag, 1. September 2023 um 09:24
An: dev@community.apache.org 
Betreff: Re: Releasing with lazy consensus
I would love to hear about it, but I believe releasing any software is an
"act of Foundation" and requires 3 explicit PMC members to say "+1" in
order for it to have legal repercussions.

So I am not so sure if releasing "software" of any kind that can be "ASF
software" should be done without voting and 3 PMC members saying +1. In
fact even the roll calls done by the board when the projects are not active
is to check "Is there enough  (3) active PMC members for the PMC to make a
release).

I believe in justified cases however, you can shorten the voting period or
even vote in "secret" and announce the voting later (for example when you
have security release). The process says that there SHOULD be 72 HRs (not
MUST) and if there are good reasons, it can be shortened. But the act of
voting and 3 +1 from the PMC members is - I believe - obligatory.

A comment on how we deal with possibly similar cases in Airflow - where we
often release up to 90(!) packages 2 times a month (!). Maybe that can help
with designing a similar process.

* we allow "bulk" voting. We prepare the "up to 90" provider packages as a
single "pack" of things we vote on. We have automation and tooling that
allows us to both release and verify  (by PMC members) all those packages
together. We also involve the contributors and those who raised relevant
issues in testing those packages (also heavily automated - example issue
generated here https://github.com/apache/airflow/issues/33305  ) - this is
nice because it allows us to streamline the process and release multiple
things together, whil allow individuals to focus on testing all such
packages individually and report it back in that single place where we
discuss the whole "release pack".

* when a bug / release/packaging/sources/problem is found in only one of
those packages (which does not invalidate the rest) the release manager can
decide to withdraw those faulty packages from that release "pack" but this
does not remove +1 votes that were given for the ones that are good.

* after releasing the "good" packages (and parallel fixing of the broken
ones) - the broken ones are released with fixes as RC2 candidates. In most
cases the fixes are really small, so the "user" testing (i.e. what has been
tested and confirmed working so far) status is carried over to the RC2
candidates. The PMC voting for those RC2 is restarted (i.e. we need three
new +1 from the PMC) .  But this time we turn on "accelerated" voting. We
agree to the rule that in this case 24H (and 3 PMC +1s) is enough for the
vote to complete.

* the 72HR -> 24 HR is only done when there are really small and few fixes
since RC1

This has been discussed at the devlist, agreed and captured in our
processes. For those interested:

Discussion about introducing RC2+ accelerated voting :
https://lists.apache.org/thread/8rpq06pobp6rnm9phnbc9fz4ky32sm16
Lazy consensus on approving it:
https://lists.apache.org/thread/cv194w1fqqykrhswhmm54zy9gnnv6kgm
Example recent vote result where two packages have been excluded due to
bugs but where release manager decided not to accelerate the voting due to
big number of fixes coming since RC1:
https://lists.apache.org/thread/1kovpkx0t2pm2xrwf61ycqdynp0kdl19
Example vote where we had 24 HR accelerated vote:
https://lists.apache.org/thread/ndm71tjdd3mmx7s904ds6sqxy84vb1fw  (BTW We
also had RC3 for google provider as another bug was found in RC2). - those
rules are transitive. RC3 was also accelerated.

I hope it helps.

J.




On Fri, Sep 1, 2023 at 8:53 AM Volkan Yazıcı  wrote:

> Is such a thing possible? It is pretty common that many Java projects have
> multiple modules having their own release cycles. Some of these modules are
> miscellaneous "utilities" to support the rest of the code base. Common
> examples I can think of are
>
>- BOM project covering a dozen other projects (e.g., `log4j-bom` for
>`log4j-core`, `log4j-layout-template-json`, etc.)
>- Utilities (e.g., `log4j-changelog` used to maintain a changelog and
>release notes for Java-based Logging Services projects)
>
> `log4j-core` release takes 72 hours due to 

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

[Christofer Dutz]

Ok …

So, off the email goes … let’s see what’s gonna happen to my inbox now 
I stuck with the Oct. 1st as I didn’t get any other feedback on selecting 
another date.

Chris

Von: Christofer Dutz 
Datum: Dienstag, 15. August 2023 um 11:20
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
So …

As I haven’t heard any other opinions, my plan is the following:


  *   Chose the date of Oct. 1st for making the change active.
  *   Apply my PR with the updated mailing-list.md.
  *   Send out the email to all dev-lists.

Any objections?


The content of the email will be as follows:

---

Subject: Mailing list threading improvements
Dear Apache Projects,

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

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

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

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

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

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

Please copy dev@community.apache.org<mailto:dev@community.apache.org> on any 
feedback.

Chris, on behalf of the Comdev PMC

---




Chris


Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 20:29
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
So here some updates to the mailing-list page:
https://github.com/apache/comdev-site/pull/127

Chris


Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 20:26
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
Hi Jarek,

I was told there’s a direct way to send to all dev-lists.
That’s one email going out for me … but thanks for that tip.
Could come in handy some time.

Chris


Von: Jarek Potiuk 
Datum: Sonntag, 13. August 2023 um 19:54
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Hey Chris - in case you are using Gmail, I can heartily recommend Streak (
streak.com). This is a very simple CRM with fabulous integration with Gmail.

For your kind of messaging it's 100% free, you can easily prepare a
(google?) spreadsheet with addresses/repos/etc, pull the whole spreadsheet
into a pipeline and send "mass email campaign" to all the projects with
customized variables from the spreadsheet. The nice thing about it is that
it actually sends those emails from your gmail UI - so it is not super
fast, but it also by-passess all the tools that detect mass mailing as
spam. It also works nicely in the way that all the emails you send are
individual threads in your Gmail "Sent" folder. With Streak, you can
single-handedly easily manage 100s of threads - responding individually to
each thread where someone responds to your email.

Also streak nicely labels the threads that are part of your pipeline so you
can see the emails that are part of your pipeline easily. You can also
manage the state of your pipeline - moving individual items to different
stages ("Sent"/ "Responded" / "Rejected" etc... etc.)

I've managed many events this way, single-handedly communicating with
hundreds of speakers, partners, sponsors, etc - it's been a life-saver, and
likely for your use case it will be perfect.

J.

On Sun, Aug 13, 2023 at 7:20 PM Christofer Dutz 
wrote:

> Ok …
>
> so in total 27 repos have managed their subjects, however not a single
> project has them handled for all their repos, so literally every project
> will be “affected”.
>
> Makes the number-crunching a bit simpler, however sill gotta send out a
> hell of a lot of individual emails.
>
> I guess I should change the page:
>
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> Before starting to send out these emails.
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 13. August 2023 um 17:54
> 

Mailing list threading improvements

[Christofer Dutz]

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

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

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

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

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

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

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

Chris, on behalf of the Comdev PMC

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

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

[Christofer Dutz]

So …

As I haven’t heard any other opinions, my plan is the following:


  *   Chose the date of Oct. 1st for making the change active.
  *   Apply my PR with the updated mailing-list.md.
  *   Send out the email to all dev-lists.

Any objections?


The content of the email will be as follows:

---

Subject: Mailing list threading improvements
Dear Apache Projects,

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

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

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

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

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

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

Please copy dev@community.apache.org<mailto:dev@community.apache.org> on any 
feedback.

Chris, on behalf of the Comdev PMC

---




Chris


Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 20:29
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
So here some updates to the mailing-list page:
https://github.com/apache/comdev-site/pull/127

Chris


Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 20:26
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
Hi Jarek,

I was told there’s a direct way to send to all dev-lists.
That’s one email going out for me … but thanks for that tip.
Could come in handy some time.

Chris


Von: Jarek Potiuk 
Datum: Sonntag, 13. August 2023 um 19:54
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Hey Chris - in case you are using Gmail, I can heartily recommend Streak (
streak.com). This is a very simple CRM with fabulous integration with Gmail.

For your kind of messaging it's 100% free, you can easily prepare a
(google?) spreadsheet with addresses/repos/etc, pull the whole spreadsheet
into a pipeline and send "mass email campaign" to all the projects with
customized variables from the spreadsheet. The nice thing about it is that
it actually sends those emails from your gmail UI - so it is not super
fast, but it also by-passess all the tools that detect mass mailing as
spam. It also works nicely in the way that all the emails you send are
individual threads in your Gmail "Sent" folder. With Streak, you can
single-handedly easily manage 100s of threads - responding individually to
each thread where someone responds to your email.

Also streak nicely labels the threads that are part of your pipeline so you
can see the emails that are part of your pipeline easily. You can also
manage the state of your pipeline - moving individual items to different
stages ("Sent"/ "Responded" / "Rejected" etc... etc.)

I've managed many events this way, single-handedly communicating with
hundreds of speakers, partners, sponsors, etc - it's been a life-saver, and
likely for your use case it will be perfect.

J.

On Sun, Aug 13, 2023 at 7:20 PM Christofer Dutz 
wrote:

> Ok …
>
> so in total 27 repos have managed their subjects, however not a single
> project has them handled for all their repos, so literally every project
> will be “affected”.
>
> Makes the number-crunching a bit simpler, however sill gotta send out a
> hell of a lot of individual emails.
>
> I guess I should change the page:
>
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> Before starting to send out these emails.
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 13. August 2023 um 17:54
> An: dev@community.apache.org 
> Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
> Hi all,
>
> So, as I’m back from my holidays … I am planning on doing the following:
>
>
>   *   Go through the repos of the projects we have and compile a list of
> the ones affected by changed defaults.
>  

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

[Christofer Dutz]

So here some updates to the mailing-list page:
https://github.com/apache/comdev-site/pull/127

Chris


Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 20:26
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
Hi Jarek,

I was told there’s a direct way to send to all dev-lists.
That’s one email going out for me … but thanks for that tip.
Could come in handy some time.

Chris


Von: Jarek Potiuk 
Datum: Sonntag, 13. August 2023 um 19:54
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Hey Chris - in case you are using Gmail, I can heartily recommend Streak (
streak.com). This is a very simple CRM with fabulous integration with Gmail.

For your kind of messaging it's 100% free, you can easily prepare a
(google?) spreadsheet with addresses/repos/etc, pull the whole spreadsheet
into a pipeline and send "mass email campaign" to all the projects with
customized variables from the spreadsheet. The nice thing about it is that
it actually sends those emails from your gmail UI - so it is not super
fast, but it also by-passess all the tools that detect mass mailing as
spam. It also works nicely in the way that all the emails you send are
individual threads in your Gmail "Sent" folder. With Streak, you can
single-handedly easily manage 100s of threads - responding individually to
each thread where someone responds to your email.

Also streak nicely labels the threads that are part of your pipeline so you
can see the emails that are part of your pipeline easily. You can also
manage the state of your pipeline - moving individual items to different
stages ("Sent"/ "Responded" / "Rejected" etc... etc.)

I've managed many events this way, single-handedly communicating with
hundreds of speakers, partners, sponsors, etc - it's been a life-saver, and
likely for your use case it will be perfect.

J.

On Sun, Aug 13, 2023 at 7:20 PM Christofer Dutz 
wrote:

> Ok …
>
> so in total 27 repos have managed their subjects, however not a single
> project has them handled for all their repos, so literally every project
> will be “affected”.
>
> Makes the number-crunching a bit simpler, however sill gotta send out a
> hell of a lot of individual emails.
>
> I guess I should change the page:
>
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> Before starting to send out these emails.
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 13. August 2023 um 17:54
> An: dev@community.apache.org 
> Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
> Hi all,
>
> So, as I’m back from my holidays … I am planning on doing the following:
>
>
>   *   Go through the repos of the projects we have and compile a list of
> the ones affected by changed defaults.
>   *   Send an email to each of the dev-lists (or whatever qualifies as
> dev-list)
>
> Gonna be a hell of a lot of work, but it’s something I strongly believe in
> being worth the effort.
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Dienstag, 8. August 2023 um 08:07
> An: dev@community.apache.org 
> Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
> Well... I'll go for it as soon as I'm back from my short holiday.
>
> Chris
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: sebb 
> Sent: Tuesday, August 8, 2023 12:16:42 AM
> To: dev@community.apache.org 
> Subject: Re: AW: [DRAFT] Email to all PMCs or Committers
>
> On Mon, 7 Aug 2023 at 13:50,  wrote:
> >
> > On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> > > Hi all,
> > >
> > > So, I think we should stay with Rich’s version of the email.
> > > Now to the next question … which list should we post this to?
> >
> > I think this should go to all dev@ lists, as those are the people
> > affected.
>
> Not all projects have dev lists, and some have multiple dev lists.
>
> Also the email needs to point out that any email filters based on
> matching subjects are likely to be affected.
> Further, this will affect all lists that receive GH notifications.
>
> > > And what do you think should we define as a date when we’ll switch?
> > > As far as I understood things, Infa merges PRs like mine on
> > > Thursdays.
> > > How much time to we want to give people to adjust their .asf.yml?
> > >
> > > Do 4 weeks make sense, or would a shorter time be better?
> > > (I mean … we all know that it really doesn’t matter if you give
> > > people a week or a year … they’ll always be surprised)
> > >
> > > The range I’m ok with would b

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

[Christofer Dutz]

Hi Jarek,

I was told there’s a direct way to send to all dev-lists.
That’s one email going out for me … but thanks for that tip.
Could come in handy some time.

Chris


Von: Jarek Potiuk 
Datum: Sonntag, 13. August 2023 um 19:54
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Hey Chris - in case you are using Gmail, I can heartily recommend Streak (
streak.com). This is a very simple CRM with fabulous integration with Gmail.

For your kind of messaging it's 100% free, you can easily prepare a
(google?) spreadsheet with addresses/repos/etc, pull the whole spreadsheet
into a pipeline and send "mass email campaign" to all the projects with
customized variables from the spreadsheet. The nice thing about it is that
it actually sends those emails from your gmail UI - so it is not super
fast, but it also by-passess all the tools that detect mass mailing as
spam. It also works nicely in the way that all the emails you send are
individual threads in your Gmail "Sent" folder. With Streak, you can
single-handedly easily manage 100s of threads - responding individually to
each thread where someone responds to your email.

Also streak nicely labels the threads that are part of your pipeline so you
can see the emails that are part of your pipeline easily. You can also
manage the state of your pipeline - moving individual items to different
stages ("Sent"/ "Responded" / "Rejected" etc... etc.)

I've managed many events this way, single-handedly communicating with
hundreds of speakers, partners, sponsors, etc - it's been a life-saver, and
likely for your use case it will be perfect.

J.

On Sun, Aug 13, 2023 at 7:20 PM Christofer Dutz 
wrote:

> Ok …
>
> so in total 27 repos have managed their subjects, however not a single
> project has them handled for all their repos, so literally every project
> will be “affected”.
>
> Makes the number-crunching a bit simpler, however sill gotta send out a
> hell of a lot of individual emails.
>
> I guess I should change the page:
>
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> Before starting to send out these emails.
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 13. August 2023 um 17:54
> An: dev@community.apache.org 
> Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
> Hi all,
>
> So, as I’m back from my holidays … I am planning on doing the following:
>
>
>   *   Go through the repos of the projects we have and compile a list of
> the ones affected by changed defaults.
>   *   Send an email to each of the dev-lists (or whatever qualifies as
> dev-list)
>
> Gonna be a hell of a lot of work, but it’s something I strongly believe in
> being worth the effort.
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Dienstag, 8. August 2023 um 08:07
> An: dev@community.apache.org 
> Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
> Well... I'll go for it as soon as I'm back from my short holiday.
>
> Chris
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: sebb 
> Sent: Tuesday, August 8, 2023 12:16:42 AM
> To: dev@community.apache.org 
> Subject: Re: AW: [DRAFT] Email to all PMCs or Committers
>
> On Mon, 7 Aug 2023 at 13:50,  wrote:
> >
> > On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> > > Hi all,
> > >
> > > So, I think we should stay with Rich’s version of the email.
> > > Now to the next question … which list should we post this to?
> >
> > I think this should go to all dev@ lists, as those are the people
> > affected.
>
> Not all projects have dev lists, and some have multiple dev lists.
>
> Also the email needs to point out that any email filters based on
> matching subjects are likely to be affected.
> Further, this will affect all lists that receive GH notifications.
>
> > > And what do you think should we define as a date when we’ll switch?
> > > As far as I understood things, Infa merges PRs like mine on
> > > Thursdays.
> > > How much time to we want to give people to adjust their .asf.yml?
> > >
> > > Do 4 weeks make sense, or would a shorter time be better?
> > > (I mean … we all know that it really doesn’t matter if you give
> > > people a week or a year … they’ll always be surprised)
> > >
> > > The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t
> > > really think we should go beyond that.
> > >
> > > What do you think?
> >
> > 4 weeks/30 days makes the most sense to me.
> >
> > --Rich
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

[Christofer Dutz]

Ok …

so in total 27 repos have managed their subjects, however not a single project 
has them handled for all their repos, so literally every project will be 
“affected”.

Makes the number-crunching a bit simpler, however sill gotta send out a hell of 
a lot of individual emails.

I guess I should change the page:
https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
Before starting to send out these emails.

Chris

Von: Christofer Dutz 
Datum: Sonntag, 13. August 2023 um 17:54
An: dev@community.apache.org 
Betreff: AW: AW: [DRAFT] Email to all PMCs or Committers
Hi all,

So, as I’m back from my holidays … I am planning on doing the following:


  *   Go through the repos of the projects we have and compile a list of the 
ones affected by changed defaults.
  *   Send an email to each of the dev-lists (or whatever qualifies as dev-list)

Gonna be a hell of a lot of work, but it’s something I strongly believe in 
being worth the effort.

Chris


Von: Christofer Dutz 
Datum: Dienstag, 8. August 2023 um 08:07
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Well... I'll go for it as soon as I'm back from my short holiday.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: sebb 
Sent: Tuesday, August 8, 2023 12:16:42 AM
To: dev@community.apache.org 
Subject: Re: AW: [DRAFT] Email to all PMCs or Committers

On Mon, 7 Aug 2023 at 13:50,  wrote:
>
> On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> > Hi all,
> >
> > So, I think we should stay with Rich’s version of the email.
> > Now to the next question … which list should we post this to?
>
> I think this should go to all dev@ lists, as those are the people
> affected.

Not all projects have dev lists, and some have multiple dev lists.

Also the email needs to point out that any email filters based on
matching subjects are likely to be affected.
Further, this will affect all lists that receive GH notifications.

> > And what do you think should we define as a date when we’ll switch?
> > As far as I understood things, Infa merges PRs like mine on
> > Thursdays.
> > How much time to we want to give people to adjust their .asf.yml?
> >
> > Do 4 weeks make sense, or would a shorter time be better?
> > (I mean … we all know that it really doesn’t matter if you give
> > people a week or a year … they’ll always be surprised)
> >
> > The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t
> > really think we should go beyond that.
> >
> > What do you think?
>
> 4 weeks/30 days makes the most sense to me.
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[Christofer Dutz]

Hi all,

So, as I’m back from my holidays … I am planning on doing the following:


  *   Go through the repos of the projects we have and compile a list of the 
ones affected by changed defaults.
  *   Send an email to each of the dev-lists (or whatever qualifies as dev-list)

Gonna be a hell of a lot of work, but it’s something I strongly believe in 
being worth the effort.

Chris


Von: Christofer Dutz 
Datum: Dienstag, 8. August 2023 um 08:07
An: dev@community.apache.org 
Betreff: Re: AW: [DRAFT] Email to all PMCs or Committers
Well... I'll go for it as soon as I'm back from my short holiday.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: sebb 
Sent: Tuesday, August 8, 2023 12:16:42 AM
To: dev@community.apache.org 
Subject: Re: AW: [DRAFT] Email to all PMCs or Committers

On Mon, 7 Aug 2023 at 13:50,  wrote:
>
> On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> > Hi all,
> >
> > So, I think we should stay with Rich’s version of the email.
> > Now to the next question … which list should we post this to?
>
> I think this should go to all dev@ lists, as those are the people
> affected.

Not all projects have dev lists, and some have multiple dev lists.

Also the email needs to point out that any email filters based on
matching subjects are likely to be affected.
Further, this will affect all lists that receive GH notifications.

> > And what do you think should we define as a date when we’ll switch?
> > As far as I understood things, Infa merges PRs like mine on
> > Thursdays.
> > How much time to we want to give people to adjust their .asf.yml?
> >
> > Do 4 weeks make sense, or would a shorter time be better?
> > (I mean … we all know that it really doesn’t matter if you give
> > people a week or a year … they’ll always be surprised)
> >
> > The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t
> > really think we should go beyond that.
> >
> > What do you think?
>
> 4 weeks/30 days makes the most sense to me.
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[Christofer Dutz]

Well... I'll go for it as soon as I'm back from my short holiday.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: sebb 
Sent: Tuesday, August 8, 2023 12:16:42 AM
To: dev@community.apache.org 
Subject: Re: AW: [DRAFT] Email to all PMCs or Committers

On Mon, 7 Aug 2023 at 13:50,  wrote:
>
> On Sat, 2023-08-05 at 15:37 +, Christofer Dutz wrote:
> > Hi all,
> >
> > So, I think we should stay with Rich’s version of the email.
> > Now to the next question … which list should we post this to?
>
> I think this should go to all dev@ lists, as those are the people
> affected.

Not all projects have dev lists, and some have multiple dev lists.

Also the email needs to point out that any email filters based on
matching subjects are likely to be affected.
Further, this will affect all lists that receive GH notifications.

> > And what do you think should we define as a date when we’ll switch?
> > As far as I understood things, Infa merges PRs like mine on
> > Thursdays.
> > How much time to we want to give people to adjust their .asf.yml?
> >
> > Do 4 weeks make sense, or would a shorter time be better?
> > (I mean … we all know that it really doesn’t matter if you give
> > people a week or a year … they’ll always be surprised)
> >
> > The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t
> > really think we should go beyond that.
> >
> > What do you think?
>
> 4 weeks/30 days makes the most sense to me.
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

AW: [DRAFT] Email to all PMCs or Committers

[Christofer Dutz]

Hi all,

So, I think we should stay with Rich’s version of the email.
Now to the next question … which list should we post this to?
And what do you think should we define as a date when we’ll switch?
As far as I understood things, Infa merges PRs like mine on Thursdays.
How much time to we want to give people to adjust their .asf.yml?

Do 4 weeks make sense, or would a shorter time be better?
(I mean … we all know that it really doesn’t matter if you give people a week 
or a year … they’ll always be surprised)

The range I’m ok with would be 2 weeks up to 4 weeks but wouldn’t really think 
we should go beyond that.

What do you think?


Chris

Von: rbo...@rcbowen.com 
Datum: Freitag, 4. August 2023 um 15:39
An: dev@community.apache.org 
Betreff: Re: [DRAFT] Email to all PMCs or Committers
On Fri, 2023-08-04 at 15:26 +0200, Jarek Potiuk wrote:
> +1. Looks way better.

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



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

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

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

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

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

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

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

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

Chris, on behalf of the Comdev PMC

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

AW: [DRAFT] Email to all PMCs or Committers

[Christofer Dutz]

Hi all and especially Rich …

I love your version … and yes … I really need to focus more on the “what you 
get”
and less on “why where you’re at sucks” sort of narrative ;-)

Chris


Von: Peter Hunsberger 
Datum: Freitag, 4. August 2023 um 15:06
An: dev@community.apache.org 
Betreff: Re: [DRAFT] Email to all PMCs or Committers
On Fri, Aug 4, 2023 at 7:45 AM  wrote:

> Ok, I propose this alternative approach - more on the "here's how
> things are getting better" tone than the "Here's how things were awful"
> tone, and half the length:
>
> 
>
>
> Subject: Mailing list threading improvements
> To: dev@
>
> Dear Apache project developers,
>
> TL;DR: We’re updating how auto-generated email from Github will be
> threaded on your mailing lists. If you want to keep the old defaults,
> details are below.
>
> We’re pleased to let you know that we’re tweaking the way that auto-
> generated email from Github will appear on your mailing lists. This
> will lead to more human-readable subject lines, and the ability of most
> modern mail clients to correctly thread discussions originating on
> Github.
>
> Background: Many project lists receive email auto-generated on Github.
> The way that the subject lines are crafted leads to messages from the
> same topic not being threaded together by most mail clients. We’re
> fixing that.
>
> The way that these messages are threaded is defined by a file -
> .asf.yml - in your git repositories. We’re changing the way that it
> will work by default if you don’t choose settings. The change will
> happen on {DATE}
>
> Details of the current default, as well as the proposed changes, are on
> this page, along with instructions on how to keep your current
> settings, if you prefer:
>
>
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
>
> Chris, on behalf of the Comdev PMC
>

+1

This seems concise and would be a welcome change

>
>
>
> On Fri, 2023-08-04 at 07:30 -0400, Rich Bowen wrote:
> > As discussed offline, I feel like the tone of this messaging is
> > wrong. Give me a bit to get to my desk and I will propose an
> > alternate draft.
> >
> > Shosholoza,
> > Rich
> >
> >
> > On Fri, Aug 4, 2023, 04:43 Christofer Dutz
> >  wrote:
> > > Hi,
> > >
> > > Here comes a draft for an email I would like to send out.
> > >
> > > Not quite sure which audience we should choose … committers,
> > > (p)pmcs?
> > >
> > > Also, not quite sure about the timeframe? As I know Infra merges
> > > PRs on Thursdays, I would propose the 17th of August 2023 as date
> > > for the change to be made. This would give project almost 2 weeks
> > > to react and adjust their .asf.yml files, if they wish to stay at
> > > the current defaults.
> > >
> > > So, I wasn’t sure, if I should add links to examples, as it would
> > > be putting the project acting as negative example in an unfortunate
> > > spotlight and using date ranges in ponymail links has been not
> > > quite successful in the past.
> > >
> > > What do you folks think?
> > >
> > >
> > > Chris
> > >
> > >
> > > --
> > >
> > >
> > > Dear {Committers/members of the Apache PMCs},
> > >
> > > over the years have we added additional options for discussing
> > > project matters on a big variety of alternate locations and systems
> > > besides email lists, such as JIRA and GitHub.
> > > Especially GitHub has been growing in acceptance, as it generally
> > > allows participating without requiring yet another login.
> > >
> > > GitHub currently allows discussing things using: GitHub Issues,
> > > GitHub PRs and GitHub Discussions.
> > > Infra has built tooling, that forwards these discussions to our
> > > mailing-lists.
> > >
> > > Unfortunately, some defaults were chosen, which have resulted in
> > > many dev-lists being swamped with emails, for which no email-client
> > > was able to implement any form of threading.
> > > Some projects simply reacted by redirecting these emails to lists,
> > > such as notifications@ or commits@.
> > > Some projects even completely gave up communicating via email lists
> > > and only “come back” for voting.
> > > Even if the requirement “If it didn’t happen on the list, it didn’t
> > > happen” sort of is fulfilled, it no longer fulfills what the core
> > > of this rule was:
> >

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

[Christofer Dutz]

Hi Roman,

Have you thought about asking Chat GPT where to post it? ;-)
(duck and cover)

Chris


Von: Roman Shaposhnik 
Datum: Freitag, 4. August 2023 um 14:26
An: ComDev 
Betreff: Short Email to committers@ highlighting our generative AI/tools 
guidance
Hi!

I was contemplating sending a really short email
to committers@ with the $subj. Who should I talk
with to get this done (or convince myself that
an email to a different ML is better ;-))?

Thanks,
Roman.

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

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

[Christofer Dutz]

Hi all,

and thanks Mark and Jarek. I fully agree with what you said.

And regarding the email: Tthat’s why I proposed in the draft email a time a few 
weeks in the future
(but not too many) and added links to what a project would need to do to keep 
things the way they are.

If a project deeply cares, that change should be super easy …
I would even volunteer to prepare the PR for this for every project that 
reaches out to me, wanting the old default.
Then all you need to do is click on the merge button of one PR and keep things 
the way they are.

Chris



Von: Jarek Potiuk 
Datum: Freitag, 4. August 2023 um 11:38
An: dev@community.apache.org 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
I personally think if it is super easy to change back, I see no
problem with making the change. "Ask for forgiveness not for
permission".

It already happened in the past that someone in the past "forced" the
projects to use previous defaults by the fact of defining it.

What was the process when it was decided then and how the projects
were participating in this decision then?

Sure, change is painful, but if in our process we do not allow for a
change we are stuck with sometimes bad decisions made in the past. And
the only way to change those decisions is well, to change them.

There were recent precedents where changes were forced on the
projects. Example was the need to "approve" every Github workflow of
every external contributor - so it's not that we've never done that.
And (contrary to that change) it was not as easy to go back. It
requires finding a somewhat hidden policy, opening a JIRA and waiting
for approval of INFRA.

In this case it's as easy as making a single commit with an update to .asf.yml.

J.

On Fri, Aug 4, 2023 at 11:29 AM sebb  wrote:
>
> This was not a fair poll - it was not open long enough.
> Also it is not representative; participation on this list is not
> required of projects.
> And people participating in the discussion are likely to be in favour.
>
> I don't think Comdev should be making decisions on behalf of other projects.
>
> Note: I am not against alllowing projects to change, but it should not
> be forced upon them.
>
> On Thu, 3 Aug 2023 at 15:56, Christofer Dutz  
> wrote:
> >
> > Hi all,
> >
> > as there seems to be general consent on this, I have taken the liberty to 
> > prepare the PRs for this:
> > https://github.com/apache/infrastructure-github-event-notifier/pull/12
> > https://github.com/apache/infrastructure-github-discussions-notifier/pull/2
> > However, have I marked them as DRAFT so they aren’t executed today.
> >
> > I think it would make sense to send out an email first, notifying projects 
> > about the coming changes and to define a date to which the changes will be 
> > applied.
> >
> > I’d be happy to prepare the email and send it out (once the 72h for this 
> > POLL are over).
> >
> > Chris
> >
> > Von: Christofer Dutz 
> > Datum: Mittwoch, 2. August 2023 um 09:47
> > An: Volkan Yazıcı 
> > Betreff: AW: [POLL] Should we ask Infra to change the defaults used to 
> > generate GitHub integration email subjecs?
> > Still giving this a bit more time (72 hours in total) as we usually do 
> > things.
> > But yeah … I guess as soon as that time is over, I’ll create an infra 
> > ticket.
> >
> > Chris
> >
> >
> > Von: Volkan Yazıcı 
> > Datum: Mittwoch, 2. August 2023 um 09:39
> > An: Christofer Dutz 
> > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to 
> > generate GitHub integration email subjecs?
> > Check. Is there (or will there be) an INFRA ticket that I can follow the 
> > implementation progress?
> >
> > On Wed, Aug 2, 2023 at 9:28 AM Christofer Dutz 
> > mailto:christofer.d...@c-ware.de>> wrote:
> > Hi Volkan,
> >
> > well I won’t be doing anything … also is this not really a vote (as we 
> > didn’t know if this is something we actually are allowed or able to vote 
> > on).
> > So my plan is to show this thread to Infra to show that there’s general 
> > support for the proposal.
> >
> > I really hope they won’t let me jump another hoop, asking me to bring this 
> > to a vote on Members@.
> >
> > But sure I think this is worth sending out to committers@ or similar list, 
> > which will make a wide range of people be informed.
> >
> > Chris
> >
> >
> > Von: Volkan Yazıcı mailto:vol...@yazi.ci>>
> > Datum: Mittwoch, 2. August 2023 um 09:22
> > An: Christofer Dutz 
> > mailto:christofer.d...@c-ware.de>>
&g

[DRAFT] Email to all PMCs or Committers

[Christofer Dutz]

Hi,

Here comes a draft for an email I would like to send out.

Not quite sure which audience we should choose … committers, (p)pmcs?

Also, not quite sure about the timeframe? As I know Infra merges PRs on 
Thursdays, I would propose the 17th of August 2023 as date for the change to be 
made. This would give project almost 2 weeks to react and adjust their .asf.yml 
files, if they wish to stay at the current defaults.

So, I wasn’t sure, if I should add links to examples, as it would be putting 
the project acting as negative example in an unfortunate spotlight and using 
date ranges in ponymail links has been not quite successful in the past.

What do you folks think?


Chris


--


Dear {Committers/members of the Apache PMCs},

over the years have we added additional options for discussing project matters 
on a big variety of alternate locations and systems besides email lists, such 
as JIRA and GitHub.
Especially GitHub has been growing in acceptance, as it generally allows 
participating without requiring yet another login.

GitHub currently allows discussing things using: GitHub Issues, GitHub PRs and 
GitHub Discussions.
Infra has built tooling, that forwards these discussions to our mailing-lists.

Unfortunately, some defaults were chosen, which have resulted in many dev-lists 
being swamped with emails, for which no email-client was able to implement any 
form of threading.
Some projects simply reacted by redirecting these emails to lists, such as 
notifications@ or commits@.
Some projects even completely gave up communicating via email lists and only 
“come back” for voting.
Even if the requirement “If it didn’t happen on the list, it didn’t happen” 
sort of is fulfilled, it no longer fulfills what the core of this rule was:
To allow someone to asynchronously participate and find out what’s happening in 
a project without requiring any form of login and to have some sort of archive 
of all discussions about Apache projects on Apache hardware.

In Comdev we have been discussing how we could possibly address this and bring 
back the usefulness of our mailing-lists.
The tooling Infra provides us with, already allows individual projects to 
change the settings of the auto-generated emails and several projects have 
already done so, with great success.

Comdev has therefore proposed to change the default settings for auto-generated 
emails sent out for GitHub.
These changes will not change anything for projects hat already manage how the 
emails should be formatted in their .asf.yml files, but it will affect all 
projects, that didn’t explicitly do that.

For all projects willing to stay at the current format, we encourage to have a 
look at this page and prepare their “.asf.yml” files accordingly: 
https://community.apache.org/contributors/mailing-lists.html
(This page currently lists the current defaults here 
https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
 as well as the proposed changes)
We will be changing the defaults on {date here}, so you still have some time to 
prepare.



Chris, on behalf of the Comdev PMC

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

[Christofer Dutz]

Hi all,

as there seems to be general consent on this, I have taken the liberty to 
prepare the PRs for this:
https://github.com/apache/infrastructure-github-event-notifier/pull/12
https://github.com/apache/infrastructure-github-discussions-notifier/pull/2
However, have I marked them as DRAFT so they aren’t executed today.

I think it would make sense to send out an email first, notifying projects 
about the coming changes and to define a date to which the changes will be 
applied.

I’d be happy to prepare the email and send it out (once the 72h for this POLL 
are over).

Chris

Von: Christofer Dutz 
Datum: Mittwoch, 2. August 2023 um 09:47
An: Volkan Yazıcı 
Betreff: AW: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
Still giving this a bit more time (72 hours in total) as we usually do things.
But yeah … I guess as soon as that time is over, I’ll create an infra ticket.

Chris


Von: Volkan Yazıcı 
Datum: Mittwoch, 2. August 2023 um 09:39
An: Christofer Dutz 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
Check. Is there (or will there be) an INFRA ticket that I can follow the 
implementation progress?

On Wed, Aug 2, 2023 at 9:28 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:
Hi Volkan,

well I won’t be doing anything … also is this not really a vote (as we didn’t 
know if this is something we actually are allowed or able to vote on).
So my plan is to show this thread to Infra to show that there’s general support 
for the proposal.

I really hope they won’t let me jump another hoop, asking me to bring this to a 
vote on Members@.

But sure I think this is worth sending out to committers@ or similar list, 
which will make a wide range of people be informed.

Chris


Von: Volkan Yazıcı mailto:vol...@yazi.ci>>
Datum: Mittwoch, 2. August 2023 um 09:22
An: Christofer Dutz 
mailto:christofer.d...@c-ware.de>>
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
[PM'ing to avoid derailing the vote thread.]

Christofer, in the email where you will announce the result, would you mind 
also sharing when the change will take place, please? This will help users to 
know when they shall expect the changes.

Kind regards.

On Wed, Aug 2, 2023 at 8:46 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:
Well,

stating the obvious, I’ll add my +1 ;-)

And yes Craig, I said the defaults … if you have explicitly configured your 
.asf.yaml subjects, they are left unchanged.

Chris


Von: Richard Zowalla mailto:rich...@zowalla.com>>
Datum: Mittwoch, 2. August 2023 um 08:10
An: dev@community.apache.org<mailto:dev@community.apache.org> 
mailto:dev@community.apache.org>>
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
+1

Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk 
mailto:ja...@potiuk.com>>:
>+1
>
>On Wed, Aug 2, 2023 at 2:15 AM Craig Russell 
>mailto:apache@gmail.com>> wrote:
>>
>> Hi Christofer,
>>
>> As long as projects with their own settings can continue to use them, I'm
>>
>> +1
>>
>> to change the defaults for all projects. If the projects don't like being 
>> able to use their lists again, they can always go back to what they had 
>> before.
>>
>> Thanks,
>> Craig
>>
>> > On Aug 1, 2023, at 05:16, Christofer Dutz 
>> > mailto:christofer.d...@c-ware.de>> wrote:
>> >
>> > Starting a new thread as the last one sort of dried up and didn’t quite 
>> > form anything actionable.
>> >
>> > Being subscribed to many of our mailing-lists and most recently looking 
>> > into every project, dev-lists when reviewing board reports, I have seen 
>> > many of our lists literally being rendered useless.
>> >
>> > Useless, because it’s almost impossible to follow these lists, as a large 
>> > percentage of the emails are:
>> >
>> >  *   Generated emails and the way they are currently generated makes it 
>> > impossible for email clients to correctly display them as threads.
>> >  *   Contain so much redundant information, that the actual start of the 
>> > header that I’m interested in reading is usually not readable on mobile 
>> > phones.
>> >  *   Most discussions have been moved away from the lists (notifications@, 
>> > commits@), having left over only skeletons in which every now and then a 
>> > vote is being handled.
>> >
>> > My proposal is to change the default settings for auto-generated GitHub 
>> > emails for all projects (not just the new ones) to be a much mo

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

[Christofer Dutz]

Well,

stating the obvious, I’ll add my +1 ;-)

And yes Craig, I said the defaults … if you have explicitly configured your 
.asf.yaml subjects, they are left unchanged.

Chris


Von: Richard Zowalla 
Datum: Mittwoch, 2. August 2023 um 08:10
An: dev@community.apache.org 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
+1

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

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

[Christofer Dutz]

Try this:
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-1|dto=2023-1-15:

Not sure why it didn’t work … if it doesn’t again, just select the date range 
on that list from 01.01.2023 to 15.01.2023

Chris


Von: Gary Gregory 
Datum: Dienstag, 1. August 2023 um 14:55
An: dev@community.apache.org 
Betreff: Re: [POLL] Should we ask Infra to change the defaults used to generate 
GitHub integration email subjecs?
I can't tell the difference between

https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
and
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18

They both use "[PR]". What am I missing?

Gary

On Tue, Aug 1, 2023, 8:17 AM Christofer Dutz 
wrote:

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

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

[Christofer Dutz]

Starting a new thread as the last one sort of dried up and didn’t quite form 
anything actionable.

Being subscribed to many of our mailing-lists and most recently looking into 
every project, dev-lists when reviewing board reports, I have seen many of our 
lists literally being rendered useless.

Useless, because it’s almost impossible to follow these lists, as a large 
percentage of the emails are:

  *   Generated emails and the way they are currently generated makes it 
impossible for email clients to correctly display them as threads.
  *   Contain so much redundant information, that the actual start of the 
header that I’m interested in reading is usually not readable on mobile phones.
  *   Most discussions have been moved away from the lists (notifications@, 
commits@), having left over only skeletons in which every now and then a vote 
is being handled.

My proposal is to change the default settings for auto-generated GitHub emails 
for all projects (not just the new ones) to be a much more condensed version.

With these changes, all existing lists, that haven’t manually configured the 
format of the emails, instantly get readable lists again.

Some would argue that there might be projects that could object these changes, 
but I would on the other hand bet that more projects would be in favor of such 
a change than not.
Those who don’t want a change, can simply go back to the old format, by 
specifying it in one commit for which we can even provide a default .asf.yaml 
snippet.

Some people expressed the wish to have longer prefixes, such as “[ISSUE]”, 
“[PULL-REQUEST]” or “[DISCUSSION]” however do these not add much information to 
the email that “[I]”, “[PR]” and “[D]” don’t and the shorter version allows 
displaying more of the subject on mobile email clients.

Here’s an example of a project list before the changes:
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
Here’s an example of the same list after using the other defaults:
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18

Here’s an example on how even ponymail is now able to display something 
happening on GitHub as a discussion you can also follow nicely via email:
https://lists.apache.org/thread/rnr9tjx9rsnqc7b5nwcf68qnp5bkr9hc

I would propose to keep the repository as part of the templates, even if since 
my PR last week was merged it’s now possible to omit that too.

I care deeply about our projects, and I would really hate to see our core 
principles being lost more and more (“If it didn’t happen on the list, it 
didn’t happen”).

You would make me really happy if I could get some general approval by you 
folks here.


Chris

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

[Christofer Dutz]

Well … that’s a bit of the problem

Infra has been giving me quite some pushback on these changes.
That’s why I didn’t just start creating PRs, but also discussing this matter in 
way too many mailing-lists.

So, I could post a perma-link to this thread and hope they’ll accept it,
Otherwise we’ll have to sort of find out “where to vote” first and then “do a 
vote” next.

Chris


Von: hans.van.akel...@gmail.com 
Datum: Freitag, 28. Juli 2023 um 16:17
An: dev@community.apache.org 
Betreff: Re: AW: AW: Changing the defaults for GitHub generated email titles?
Does this really need a vote?

If Infra agrees to change the defaults and it makes your life checking the 
mailing lists simpler it’s a win for everyone.
We (Apache Hop) have also implemented the suggestion you have made and I’m very 
pleased with the results.

As long as it is communicated in a timely manner and with a way for projects to 
revert it (which would be providing the lines we should add to the asf.yml to 
keep the current format) I do not really see an issue.

Though I do think the default format should still include the repository name.
It might be overkill for single repository projects but I think most projects 
have multiple repositories (even PLC4X has 3 of them so not sure how you are 
keeping the mails separated)


Cheers,
Hans
On 28 Jul 2023 at 15:41 +0200, Christofer Dutz , 
wrote:
> Well,
>
> That’s the problem … I am not sure who has the authority to vote on this.
> The only thing I know is that when I tried bringing this up, I was guided 
> from A to B, then from B to C, and on it goes.
>
> I think the issue is one rendering the mailing lists of many of our projects 
> pretty much useless, which I consider a community problem.
> However, ComDev doesn’t have any form of authority besides deciding which 
> stickers to order ;-)
> I would however like to see ComDev get a bit more teeth and actually start 
> having a say in community related topics.
>
> I could imagine that I could also ask on Members, but it sort of feels like 
> carrying a bloody steak into the hungry lion’s den.
>
> So … anyone got any pointers to if and where we should decide on defaults 
> like this?
>
> Chris
>
>
>
>
>
> Von: rbo...@rcbowen.com 
> Datum: Freitag, 28. Juli 2023 um 15:11
> An: dev@community.apache.org 
> Betreff: Re: AW: Changing the defaults for GitHub generated email titles?
> On Thu, 2023-07-27 at 19:46 +, Christofer Dutz wrote:
> > Ok,
> >
> > so after the discussion didn’t come up with any objections. I
> > prepared a PR and that was merged today.
> > Now the templates no longer have to have a mandatory “repository”
> > variable ;-)
> >
> > I updated the PLC4X settings and it seems to be working nicely.
> >
> > So … where are we on this discussion?
> > I would still like to change the defaults to the patterns I suggested
> > (including the repository).
> >
> > What’s your thoughts? Should I simply start a vote?
>
> Who's voting? That is, who has the authority to make this change? Yes,
> I'm in favor of such a change, but surely Infra are the folks that have
> the actual reins here, right?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org

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

[Christofer Dutz]

Well,

That’s the problem … I am not sure who has the authority to vote on this.
The only thing I know is that when I tried bringing this up, I was guided from 
A to B, then from B to C, and on it goes.

I think the issue is one rendering the mailing lists of many of our projects 
pretty much useless, which I consider a community problem.
However, ComDev doesn’t have any form of authority besides deciding which 
stickers to order ;-)
I would however like to see ComDev get a bit more teeth and actually start 
having a say in community related topics.

I could imagine that I could also ask on Members, but it sort of feels like 
carrying a bloody steak into the hungry lion’s den.

So … anyone got any pointers to if and where we should decide on defaults like 
this?

Chris





Von: rbo...@rcbowen.com 
Datum: Freitag, 28. Juli 2023 um 15:11
An: dev@community.apache.org 
Betreff: Re: AW: Changing the defaults for GitHub generated email titles?
On Thu, 2023-07-27 at 19:46 +, Christofer Dutz wrote:
> Ok,
>
> so after the discussion didn’t come up with any objections. I
> prepared a PR and that was merged today.
> Now the templates no longer have to have a mandatory “repository”
> variable ;-)
>
> I updated the PLC4X settings and it seems to be working nicely.
>
> So … where are we on this discussion?
> I would still like to change the defaults to the patterns I suggested
> (including the repository).
>
> What’s your thoughts? Should I simply start a vote?

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

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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi Kelly,

Well, I’m proposing to change the defaults for email automatically sent from 
GitHub for PRs, Issues and Discussions.
I’m not changing anything right now … I just had one check removed that 
validates the custom patterns a project has in its .asf.yaml
So technically this change shouldn’t have changed anything at all … it just 
allows you to do it now, and I guess so far only PLC4X uses this feature.

Chris

Von: Kelly Oglesbee 
Datum: Donnerstag, 27. Juli 2023 um 22:12
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
exactly what emails are you changing, because I'm experiencing problems
with my emails on my device?

On Thu, Jul 27, 2023, 3:52 PM Gary Gregory  wrote:

> I'm OK with a vote, make sure you explain what -1 means in this context
> (count vs veto)
>
>
> TY!
> Gary
>
> On Thu, Jul 27, 2023, 3:46 PM Christofer Dutz 
> wrote:
>
> > Ok,
> >
> > so after the discussion didn’t come up with any objections. I prepared a
> > PR and that was merged today.
> > Now the templates no longer have to have a mandatory “repository”
> variable
> > ;-)
> >
> > I updated the PLC4X settings and it seems to be working nicely.
> >
> > So … where are we on this discussion?
> > I would still like to change the defaults to the patterns I suggested
> > (including the repository).
> >
> > What’s your thoughts? Should I simply start a vote?
> >
> > Chris
> >
> >
> >
> > Von: Christofer Dutz 
> > Datum: Mittwoch, 19. Juli 2023 um 14:35
> > An: dev@community.apache.org 
> > Betreff: AW: Changing the defaults for GitHub generated email titles?
> > Hi all,
> >
> > So, I’ve tracked down the requirement to the test, that requires the
> > “repository” variable,
> > But it doesn’t really explain why it’s required. I was told that it’s for
> > some 20 year old reason, however that simply can’t apply to the custom
> > email templates for GitHub ;-)
> >
> > So, I opened a discussion thread
> > https://lists.apache.org/thread/wz6f71wovzsz0nk6bdpgs8m17f07o2ko
> > Feel free to add your comments to it.
> >
> > Chris
> >
> >
> > Von: Christofer Dutz 
> > Datum: Dienstag, 11. Juli 2023 um 16:29
> > An: dev@community.apache.org 
> > Betreff: AW: Changing the defaults for GitHub generated email titles?
> > I have absolutely no idea … just whenever you leave it away the system
> > starts yelling at you, telling you that it’s required ;-)
> > If the computer says so … I gotta obey ;-)
> >
> > Von: Kelly Oglesbee 
> > Datum: Dienstag, 11. Juli 2023 um 15:00
> > An: dev@community.apache.org 
> > Betreff: Re: Changing the defaults for GitHub generated email titles?
> > Why id this necessary?
> >
> > On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz  >
> > wrote:
> >
> > > Hi Phil,
> > >
> > > Well, you can somewhat reduce it to whatever you like … however there
> > > seems to be one limitation, which I can’t quite explain.
> > > For some reason you need to have the repository name as part of the
> > > subject line. That’s why I added it to the end as there it didn’t
> > interrupt
> > > my speed-reading and didn’t show up on my phone.
> > >
> > > And yeah … I agree that I also prefer the super-minimal prefixes [PR]
> for
> > > Pull-Requests [I] for Issues and [D] for Discussions.
> > > I think it takes me something round half a second to know that it’s a
> PR,
> > > Issue or Discussion.
> > > Generally, I could even live without them all together as it doesn’t
> > > really matter, if a discussion is about a PR, Issue or just a
> > > general-purpose discussion.
> > > In an all-email workflow, we never had these prefixes before …
> everything
> > > was just a discussion.
> > > But if you ask me .. I’d keep the minimal prefixes, but be in favor of
> > the
> > > smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] …
> > > well … I guess that was why I chose these defaults for the projects I
> > > could change it ;-)
> > >
> > > Chris
> > >
> > >
> > > Von: Phil Steitz 
> > > Datum: Mittwoch, 5. Juli 2023 um 20:57
> > > An: dev@community.apache.org 
> > > Betreff: Re: Changing the defaults for GitHub generated email titles?
> > > +1 from another Commons contributor drowning in the flood of cruft on
> > > commons-dev.  Shorter subject lines would be great.  I don't know if
> the
> > > tooling would support or 

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Ok,

so after the discussion didn’t come up with any objections. I prepared a PR and 
that was merged today.
Now the templates no longer have to have a mandatory “repository” variable ;-)

I updated the PLC4X settings and it seems to be working nicely.

So … where are we on this discussion?
I would still like to change the defaults to the patterns I suggested 
(including the repository).

What’s your thoughts? Should I simply start a vote?

Chris



Von: Christofer Dutz 
Datum: Mittwoch, 19. Juli 2023 um 14:35
An: dev@community.apache.org 
Betreff: AW: Changing the defaults for GitHub generated email titles?
Hi all,

So, I’ve tracked down the requirement to the test, that requires the 
“repository” variable,
But it doesn’t really explain why it’s required. I was told that it’s for some 
20 year old reason, however that simply can’t apply to the custom email 
templates for GitHub ;-)

So, I opened a discussion thread 
https://lists.apache.org/thread/wz6f71wovzsz0nk6bdpgs8m17f07o2ko
Feel free to add your comments to it.

Chris


Von: Christofer Dutz 
Datum: Dienstag, 11. Juli 2023 um 16:29
An: dev@community.apache.org 
Betreff: AW: Changing the defaults for GitHub generated email titles?
I have absolutely no idea … just whenever you leave it away the system starts 
yelling at you, telling you that it’s required ;-)
If the computer says so … I gotta obey ;-)

Von: Kelly Oglesbee 
Datum: Dienstag, 11. Juli 2023 um 15:00
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
Why id this necessary?

On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz 
wrote:

> Hi Phil,
>
> Well, you can somewhat reduce it to whatever you like … however there
> seems to be one limitation, which I can’t quite explain.
> For some reason you need to have the repository name as part of the
> subject line. That’s why I added it to the end as there it didn’t interrupt
> my speed-reading and didn’t show up on my phone.
>
> And yeah … I agree that I also prefer the super-minimal prefixes [PR] for
> Pull-Requests [I] for Issues and [D] for Discussions.
> I think it takes me something round half a second to know that it’s a PR,
> Issue or Discussion.
> Generally, I could even live without them all together as it doesn’t
> really matter, if a discussion is about a PR, Issue or just a
> general-purpose discussion.
> In an all-email workflow, we never had these prefixes before … everything
> was just a discussion.
> But if you ask me .. I’d keep the minimal prefixes, but be in favor of the
> smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] …
> well … I guess that was why I chose these defaults for the projects I
> could change it ;-)
>
> Chris
>
>
> Von: Phil Steitz 
> Datum: Mittwoch, 5. Juli 2023 um 20:57
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> +1 from another Commons contributor drowning in the flood of cruft on
> commons-dev.  Shorter subject lines would be great.  I don't know if the
> tooling would support or can be customized for Commons, but one thing that
> would help would be to uniformly drop the word "Commons", so we go back to
> what we did when we actually used the dev list for discussion [Commons-Foo]
> is just [Foo].  There is also no value in the [GitHub] prefix in the
> messages from there.  All PRs come from there.  Probably should talk about
> this on Commons-dev (maybe with some special decorations on the subject
> line so people will see it amidst all of the bot stuff :)
>
> Phil
>
> On Mon, Jul 3, 2023 at 5:48 AM Gary Gregory 
> wrote:
>
> > Thanks for sharing these links; what a great start :-)
> >
> > I'm pretty sure the Commons community will welcome these kinds of
> > changes where a complaint has been the "flood" of emails from GitHub,
> > so hopefully this will help.
> >
> > For my money though, I'd prefer much shorter subject prefixes, even to
> > the extreme, I'll just learn the codes, otherwise, it's impossible to
> > read on my phone, which would be counterproductive (for me).
> >
> > For example, [BUILD-FAILURE] -> [BUILD-FAIL] -> [BUILD-F] -> [B-F],
> > just something much shorter, again, think phone. B means Build, F
> > means Fail, that kinda mapping. I'm not sure where the mapping would
> > be best documented, perhaps on each project's mailing list page.
> >
> > Gary
> >
> > On Mon, Jul 3, 2023 at 8:12 AM Christofer Dutz
> >  wrote:
> > >
> > > Hi all,
> > >
> > > So here’s an example of one week’s email traffic on one project before
> > and after the config changes:
> > >
> > > (Sorry for putting the Spotlight on you streampipes folks, but this is

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi all,

So, I’ve tracked down the requirement to the test, that requires the 
“repository” variable,
But it doesn’t really explain why it’s required. I was told that it’s for some 
20 year old reason, however that simply can’t apply to the custom email 
templates for GitHub ;-)

So, I opened a discussion thread 
https://lists.apache.org/thread/wz6f71wovzsz0nk6bdpgs8m17f07o2ko
Feel free to add your comments to it.

Chris


Von: Christofer Dutz 
Datum: Dienstag, 11. Juli 2023 um 16:29
An: dev@community.apache.org 
Betreff: AW: Changing the defaults for GitHub generated email titles?
I have absolutely no idea … just whenever you leave it away the system starts 
yelling at you, telling you that it’s required ;-)
If the computer says so … I gotta obey ;-)

Von: Kelly Oglesbee 
Datum: Dienstag, 11. Juli 2023 um 15:00
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
Why id this necessary?

On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz 
wrote:

> Hi Phil,
>
> Well, you can somewhat reduce it to whatever you like … however there
> seems to be one limitation, which I can’t quite explain.
> For some reason you need to have the repository name as part of the
> subject line. That’s why I added it to the end as there it didn’t interrupt
> my speed-reading and didn’t show up on my phone.
>
> And yeah … I agree that I also prefer the super-minimal prefixes [PR] for
> Pull-Requests [I] for Issues and [D] for Discussions.
> I think it takes me something round half a second to know that it’s a PR,
> Issue or Discussion.
> Generally, I could even live without them all together as it doesn’t
> really matter, if a discussion is about a PR, Issue or just a
> general-purpose discussion.
> In an all-email workflow, we never had these prefixes before … everything
> was just a discussion.
> But if you ask me .. I’d keep the minimal prefixes, but be in favor of the
> smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] …
> well … I guess that was why I chose these defaults for the projects I
> could change it ;-)
>
> Chris
>
>
> Von: Phil Steitz 
> Datum: Mittwoch, 5. Juli 2023 um 20:57
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> +1 from another Commons contributor drowning in the flood of cruft on
> commons-dev.  Shorter subject lines would be great.  I don't know if the
> tooling would support or can be customized for Commons, but one thing that
> would help would be to uniformly drop the word "Commons", so we go back to
> what we did when we actually used the dev list for discussion [Commons-Foo]
> is just [Foo].  There is also no value in the [GitHub] prefix in the
> messages from there.  All PRs come from there.  Probably should talk about
> this on Commons-dev (maybe with some special decorations on the subject
> line so people will see it amidst all of the bot stuff :)
>
> Phil
>
> On Mon, Jul 3, 2023 at 5:48 AM Gary Gregory 
> wrote:
>
> > Thanks for sharing these links; what a great start :-)
> >
> > I'm pretty sure the Commons community will welcome these kinds of
> > changes where a complaint has been the "flood" of emails from GitHub,
> > so hopefully this will help.
> >
> > For my money though, I'd prefer much shorter subject prefixes, even to
> > the extreme, I'll just learn the codes, otherwise, it's impossible to
> > read on my phone, which would be counterproductive (for me).
> >
> > For example, [BUILD-FAILURE] -> [BUILD-FAIL] -> [BUILD-F] -> [B-F],
> > just something much shorter, again, think phone. B means Build, F
> > means Fail, that kinda mapping. I'm not sure where the mapping would
> > be best documented, perhaps on each project's mailing list page.
> >
> > Gary
> >
> > On Mon, Jul 3, 2023 at 8:12 AM Christofer Dutz
> >  wrote:
> > >
> > > Hi all,
> > >
> > > So here’s an example of one week’s email traffic on one project before
> > and after the config changes:
> > >
> > > (Sorry for putting the Spotlight on you streampipes folks, but this is
> > the best positive example I know)
> > >
> > > Before the change:
> > >
> >
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
> > > Here you can see, that:
> > > a) It’s hard to see what something is about as the prefix is very large
> > > b) The only grouping happening is the same person doing the same thing
> > on one issue (commenting on an issue for example)
> > >
> > > Also, one week on the same list, with updated settings:
> > >
> >
> https://lists.apache.or

AW: Anyone interested in initiating an ALC Frankfurt?

[Christofer Dutz]

Hi Christian,

Well, I thought of ALCs sort of something you know there’s one meeting per 
month, every time about a different Apache Project … would sort of require 
quite a bit of coordination more, I guess.
With “Frankfurt” I could build up a list of companies willing to host such an 
event … with “Germany” we’d sort of need to figure out: where are the 
interest-groups located and where could we host the event.

But … if you think this would be something worth trying. Happy to try it out.

Chris

Von: Christian Grobmeier 
Datum: Dienstag, 11. Juli 2023 um 22:05
An: dev@community.apache.org 
Betreff: Re: Anyone interested in initiating an ALC Frankfurt?


On Tue, Jul 11, 2023, at 14:56, Christofer Dutz wrote:
> Ok … so I guess there’s no real interest in such a thing.
>
> Probably creating an ALC Germany sort of sounds like a stupid idea …
> one sort of contradicting the L in Local ;-)

Germany is very local for somebody living in a country like India :-)

Seriously, a ALC Germany, where the attendees of such conferences travel from 
city to city doesn't sound too bad for me. In cooperation with Java Usergroups 
this may work. I have done something similar with fellows for Apache Struts a 
few years back



>
> Chris
>
> Von: Richard Zowalla 
> Datum: Mittwoch, 14. Juni 2023 um 09:10
> An: dev@community.apache.org 
> Betreff: Re: Anyone interested in initiating an ALC Frankfurt?
> Hi Chris,
>
> for me, Frankfurt is (with a 2.5h train ride) a bit too far away but I
> might be able to occussionally lurk in ;-) - so I wouldn't be able to
> organize things, etc.
>
> Gruß from Heilbronn / Germany
> Richard
>
> Am Mittwoch, dem 14.06.2023 um 06:35 + schrieb Christofer Dutz:
>> Hi all,
>>
>> I just wanted to bring forward the idea of initiating an ALC chapter
>> in Germany/Frankfurt.
>>
>> I noticed that many meetups near Frankfurt have shifted away from
>> reporting about real project, toward more theoretical content.
>> However, have I heard quite a few people that are a bit unhappy with
>> that.
>>
>> Having an ALC Frankfurt (or whatever we’d call it) would allow us to
>> promote our awesome Apache projects a bit more.
>>
>> I would even already have a place where we could regularly have such
>> meetings, as my former employer codecentric would be happy to
>> accommodate us.
>>
>> What do you folks 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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

I have absolutely no idea … just whenever you leave it away the system starts 
yelling at you, telling you that it’s required ;-)
If the computer says so … I gotta obey ;-)

Von: Kelly Oglesbee 
Datum: Dienstag, 11. Juli 2023 um 15:00
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
Why id this necessary?

On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz 
wrote:

> Hi Phil,
>
> Well, you can somewhat reduce it to whatever you like … however there
> seems to be one limitation, which I can’t quite explain.
> For some reason you need to have the repository name as part of the
> subject line. That’s why I added it to the end as there it didn’t interrupt
> my speed-reading and didn’t show up on my phone.
>
> And yeah … I agree that I also prefer the super-minimal prefixes [PR] for
> Pull-Requests [I] for Issues and [D] for Discussions.
> I think it takes me something round half a second to know that it’s a PR,
> Issue or Discussion.
> Generally, I could even live without them all together as it doesn’t
> really matter, if a discussion is about a PR, Issue or just a
> general-purpose discussion.
> In an all-email workflow, we never had these prefixes before … everything
> was just a discussion.
> But if you ask me .. I’d keep the minimal prefixes, but be in favor of the
> smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] …
> well … I guess that was why I chose these defaults for the projects I
> could change it ;-)
>
> Chris
>
>
> Von: Phil Steitz 
> Datum: Mittwoch, 5. Juli 2023 um 20:57
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> +1 from another Commons contributor drowning in the flood of cruft on
> commons-dev.  Shorter subject lines would be great.  I don't know if the
> tooling would support or can be customized for Commons, but one thing that
> would help would be to uniformly drop the word "Commons", so we go back to
> what we did when we actually used the dev list for discussion [Commons-Foo]
> is just [Foo].  There is also no value in the [GitHub] prefix in the
> messages from there.  All PRs come from there.  Probably should talk about
> this on Commons-dev (maybe with some special decorations on the subject
> line so people will see it amidst all of the bot stuff :)
>
> Phil
>
> On Mon, Jul 3, 2023 at 5:48 AM Gary Gregory 
> wrote:
>
> > Thanks for sharing these links; what a great start :-)
> >
> > I'm pretty sure the Commons community will welcome these kinds of
> > changes where a complaint has been the "flood" of emails from GitHub,
> > so hopefully this will help.
> >
> > For my money though, I'd prefer much shorter subject prefixes, even to
> > the extreme, I'll just learn the codes, otherwise, it's impossible to
> > read on my phone, which would be counterproductive (for me).
> >
> > For example, [BUILD-FAILURE] -> [BUILD-FAIL] -> [BUILD-F] -> [B-F],
> > just something much shorter, again, think phone. B means Build, F
> > means Fail, that kinda mapping. I'm not sure where the mapping would
> > be best documented, perhaps on each project's mailing list page.
> >
> > Gary
> >
> > On Mon, Jul 3, 2023 at 8:12 AM Christofer Dutz
> >  wrote:
> > >
> > > Hi all,
> > >
> > > So here’s an example of one week’s email traffic on one project before
> > and after the config changes:
> > >
> > > (Sorry for putting the Spotlight on you streampipes folks, but this is
> > the best positive example I know)
> > >
> > > Before the change:
> > >
> >
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
> > > Here you can see, that:
> > > a) It’s hard to see what something is about as the prefix is very large
> > > b) The only grouping happening is the same person doing the same thing
> > on one issue (commenting on an issue for example)
> > >
> > > Also, one week on the same list, with updated settings:
> > >
> >
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18
> > :
> > > Here you can see:
> > > a) Greatly reduced number of threads
> > > b) Threads are grouped together
> > > c) You can actually follow a thread
> > > (The reason so many threads start with “RE:” is that the initial post
> > seems to be outside of the date-range of that week and the reason for one
> > or two long discussion titles, was they changed the config on 16.06.2023)
> > >
> > > Hope this brings a bit more context for some.
> &

AW: Anyone interested in initiating an ALC Frankfurt?

[Christofer Dutz]

Ok … so I guess there’s no real interest in such a thing.

Probably creating an ALC Germany sort of sounds like a stupid idea … one sort 
of contradicting the L in Local ;-)

Chris

Von: Richard Zowalla 
Datum: Mittwoch, 14. Juni 2023 um 09:10
An: dev@community.apache.org 
Betreff: Re: Anyone interested in initiating an ALC Frankfurt?
Hi Chris,

for me, Frankfurt is (with a 2.5h train ride) a bit too far away but I
might be able to occussionally lurk in ;-) - so I wouldn't be able to
organize things, etc.

Gruß from Heilbronn / Germany
Richard

Am Mittwoch, dem 14.06.2023 um 06:35 + schrieb Christofer Dutz:
> Hi all,
>
> I just wanted to bring forward the idea of initiating an ALC chapter
> in Germany/Frankfurt.
>
> I noticed that many meetups near Frankfurt have shifted away from
> reporting about real project, toward more theoretical content.
> However, have I heard quite a few people that are a bit unhappy with
> that.
>
> Having an ALC Frankfurt (or whatever we’d call it) would allow us to
> promote our awesome Apache projects a bit more.
>
> I would even already have a place where we could regularly have such
> meetings, as my former employer codecentric would be happy to
> accommodate us.
>
> What do you folks think?
>
> Chris
>


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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi all,

So here’s an example of one week’s email traffic on one project before and 
after the config changes:

(Sorry for putting the Spotlight on you streampipes folks, but this is the best 
positive example I know)

Before the change:
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
Here you can see, that:
a) It’s hard to see what something is about as the prefix is very large
b) The only grouping happening is the same person doing the same thing on one 
issue (commenting on an issue for example)

Also, one week on the same list, with updated settings:
https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18:
Here you can see:
a) Greatly reduced number of threads
b) Threads are grouped together
c) You can actually follow a thread
(The reason so many threads start with “RE:” is that the initial post seems to 
be outside of the date-range of that week and the reason for one or two long 
discussion titles, was they changed the config on 16.06.2023)

Hope this brings a bit more context for some.

Chris



Von: Shane Curcuru 
Datum: Freitag, 30. Juni 2023 um 23:20
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
Christofer Dutz wrote on 6/30/23 3:49 AM:
...snip...
> So in general, I would like to change the defaults used by the GitHub tooling 
> to the ones I proposed in 
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
>  . Quite a number of projects have adopted these settings:
> Like StreamPipes: 
> https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M

+1 to giving this several more days of review and refinement, and then
holding a vote to make this a ComDev PMC recommendation of best practice
and then working (separately) on how to announce and make any changes.

A couple of things I'd love to see:

- A clear example of a before and after within a single project.  Come
up with a specific Ponymail date search URL that shows one week of
old-style notifications on a dev@ list, and then a second URL that shows
a week of new-style notifications from the same dev@ list.  Directly
seeing that difference would really help cement "yes, let's do it!"

- Changing Chris' description page above to clearly show the best
practice first, and then talk about how to find options for projects
that want to customize.  The page as written now is good at helping
convince someone new that 1) this is an easy change, and 2) this is a
good idea.

When we work on communications to PMCs, we need a "How-To setup best
practices for GH notifications" guide that focuses on the *why*
"Inclusion and transparency", and then the *steps to do/configure* which
would be brief description of asfyaml stuff, and start with the best
practice configuration, explaining what it does.

After that in the doc, include the original GH notifications and other
pointers to technical reference.

Thinking ahead, I'd be happy voting to send out PMCs email saying "the
default notifications are going to change on date X; email here to
opt-out".  Keep track of opt-outs, and then change defaults for all.

--
- Shane
   ComDev PMC
   The Apache Software Foundation


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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi all,

Aggregating responses to multiple emails:


  *   Sending an Email ahead of time with a code-snippet that allows keeping 
the old defaults (If a project wants to keep the old, all they need to do is 
copy that to their .asf.yaml-file and nothing will change)
  *   About different Prefixes: Absolutely fine with longer prefixes. As I 
said, just wanted to keep them as short as possible for mobile reading
  *   About breaking automation projects might have set up: I would absolutely 
doubt there is even a single Apache project that has setup automation based on 
these emails. I could imagine that there is a hand full of companies paying 
attention to them, but in this case, I would suggest optimizing for community 
and not these companies.

Chris


Von: Dave Fisher 
Datum: Freitag, 30. Juni 2023 um 15:38
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?


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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

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.

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

AW: Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi all,

well, I removed the issue numbers, as I thought that they only bring very 
limited value to the reader and the title itself gives way more context.
Of course, could we add them, but then I would recommend to add them at the end 
(just like the repository name).

And the reason I chose the “I”, “PR” and “D” was that I am subscribed to many 
lists and if I’m travelling, I read a lot of them on my phone (as I know others 
do too). I just wanted to keep the static stuff as short as possible to allow 
displaying more of the subject on small screens.

But I’m totally open to discussing the format as I am just 100% sure the 
current default is harmful.

Chris



Von: sebb 
Datum: Freitag, 30. Juni 2023 um 10:36
An: dev@community.apache.org 
Betreff: Re: Changing the defaults for GitHub generated email titles?
Mostly agree, though I wonder why the numbers have been dropped from
the shorter titles.

[D] could be [DISCUSS] or [RFC] perhaps.

On Fri, 30 Jun 2023 at 09:20, Christopher  wrote:
>
> I think this would be really great. I'm not a big fan of the [I] and [D]
> topics, though. I think I'd rather see [ISSUE] and [DISCUSSION], but either
> way, the ability to group emails is a big improvement. I'd also prefer to
> always include [GH] as a topic tag, so for example, [GH][ISSUE], so if
> people don't redirect them to another list, I can filter them out more
> easily. The reason for that is that I will still prefer to manage my
> notification subscriptions directly with GitHub, and prefer to suppress
> those on the lists by default.
>
> On Fri, Jun 30, 2023, 03:50 Christofer Dutz 
> wrote:
>
> > Hi all,
> >
> > So, we have made it possible to “integrate” GitHub PRs, Issues and now
> > even Discussions by having infra auto-generate emails.
> > However, is the default setting for these just completely useless (in my
> > opinion).
> >
> > Without taking action currently there are only the following options:
> >
> >   *   A project just redirects the emails to another lists (commits@ or
> > notifications@ or whatever)
> >   *   A project gets a totally human-unreadable dev-list.
> >
> > As I see my role as a director in actually having a look at all of our
> > mailinglists this has become more and more painful over time.
> > But it got me thinking: If I’m having problems being able to see what a
> > project is up to – so will others.
> >
> > Some of the projects will have received many comments from me over the
> > past few months, as I’m trying to make dev-lists usable again.
> > Infra did add the ability to customize the default templates for the
> > subjects of auto-generated emails. And last month a PR of mine got merged,
> > that also allowed the customization of GitHub Discussions.
> > https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> >
> > 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.
> >
> > However, I think at the ASF we should be optimizing for people and not for
> > bots. Right now we have many projects where following the list is very
> > difficult and therefore we’re losing a big part of our transparency.
> >
> > I’m bringing this here as I think Comdev is where such discussions should
> > be had.
> >
> > So in general, I would like to change the defaults used by the GitHub
> > tooling to the ones I proposed in
> > https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> > . Quite a number of projects have adopted these settings:
> > Like StreamPipes:
> > https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M
> >
> > What do you folks think?
> >
> > Chris
> >
> >

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

Changing the defaults for GitHub generated email titles?

[Christofer Dutz]

Hi all,

So, we have made it possible to “integrate” GitHub PRs, Issues and now even 
Discussions by having infra auto-generate emails.
However, is the default setting for these just completely useless (in my 
opinion).

Without taking action currently there are only the following options:

  *   A project just redirects the emails to another lists (commits@ or 
notifications@ or whatever)
  *   A project gets a totally human-unreadable dev-list.

As I see my role as a director in actually having a look at all of our 
mailinglists this has become more and more painful over time.
But it got me thinking: If I’m having problems being able to see what a project 
is up to – so will others.

Some of the projects will have received many comments from me over the past few 
months, as I’m trying to make dev-lists usable again.
Infra did add the ability to customize the default templates for the subjects 
of auto-generated emails. And last month a PR of mine got merged, that also 
allowed the customization of GitHub Discussions. 
https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

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.

However, I think at the ASF we should be optimizing for people and not for 
bots. Right now we have many projects where following the list is very 
difficult and therefore we’re losing a big part of our transparency.

I’m bringing this here as I think Comdev is where such discussions should be 
had.

So in general, I would like to change the defaults used by the GitHub tooling 
to the ones I proposed in 
https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
 . Quite a number of projects have adopted these settings:
Like StreamPipes: 
https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M

What do you folks think?

Chris

Anyone interested in initiating an ALC Frankfurt?

[Christofer Dutz]

Hi all,

I just wanted to bring forward the idea of initiating an ALC chapter in 
Germany/Frankfurt.

I noticed that many meetups near Frankfurt have shifted away from reporting 
about real project, toward more theoretical content.
However, have I heard quite a few people that are a bit unhappy with that.

Having an ALC Frankfurt (or whatever we’d call it) would allow us to promote 
our awesome Apache projects a bit more.

I would even already have a place where we could regularly have such meetings, 
as my former employer codecentric would be happy to accommodate us.

What do you folks think?

Chris

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

[Christofer Dutz]

Hi,

There are many projects, where “main” contains the latest released version and 
„develop“ is for development.
Others use “main” for development and something else for releases.

That’s why I’m suggesting naming the threads according to what they are used 
for.

“main” for a developer is probably the branch he does his most work on (aka 
“develop”).
“main” for a user is probably the branch that he uses for using the framework 
(aka “release”).

With “release” and “develop” I think it’s absolutely clear what is on which 
branch.

That was why I suggested it.

Chris


Von: tison 
Datum: Sonntag, 2. April 2023 um 14:18
An: dev@community.apache.org 
Betreff: Re: Standardise on 'main' as the default branch?
> Name the branch, on which development happens "develop" and the one that
contains the released versions "releases". With "main" you never really
know what it's used for.

To me, "main" is always "develop".

Best,
tison.


sebb  于2023年4月2日周日 19:34写道：

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

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

[Christofer Dutz]

I would like to make a slightly different proposal.
Name the branch, on which development happens "develop" and the one that 
contains the released versions "releases". With "main" you never really know 
what it's used for.

But I think I brought this up multiple times before, so if be +1 on a change.

Chris

Gesendet von Outlook für Android

From: Willem Jiang 
Sent: Sunday, April 2, 2023 10:19:44 AM
To: dev@community.apache.org 
Subject: Re: Standardise on 'main' as the default branch?

+1 for it.

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Sat, Apr 1, 2023 at 8:11 PM sebb  wrote:
>
> All bar one of the 4 comdev Git repos use 'main' as the default branch.
>
> I think we should standardise on that going forward, and change the
> default branch for comdev-site.
>
> Agreed?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Tidelift

[Christofer Dutz]

Another thing I would be interested in:

Is Tidelift continuing with the practice to select which projects are worth 
providing support for?

Just asking, because we don’t just have the big projects everyone knows, but 
also a load of small ones.
My experience with trying to get PLC4X listed with Tidelift was catastrophic.

Chris

From: Jarek Potiuk 
Date: Sunday, 6. November 2022 at 22:41
To: dev@community.apache.org 
Subject: Re: Tidelift
Yep. That's one of the main "DON'Ts" that are going to be there.

On Tue, Nov 1, 2022 at 9:03 AM Bertrand Delacretaz 
wrote:

> Ralph Goers  wrote:
> > ...I personally have no problem having a project support page
> > that lists the individuals who accept GitHub sponsorships. Likewise I
> > think it would be OK to list the people who are accepting sponsorship
> from
> > Tidelift
>
> +1, and IMO such pages should include a disclaimer that there's no
> guarantee that the contributions of sponsored committers will be
> accepted by the project, like at [1] maybe.
>
> That's obvious for ASF community members, but maybe not for their sponsors.
>
> -Bertrand
>
> [1] https://community.apache.org/committers/funding-disclaimer.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: European Commission Workshop day on Open-Source Sustainability

[Christofer Dutz]

Hi all,

Thanks for taking this coordination over.

They did disarm my worries, that the panelists would be from the industry. It 
seems this is not the case.

But they do explicitly welcome suggestions for people to be acting as panelist 
on these sessions.
So, we can be more actively involved. If we want to.

And I agree .. this is not something we can sit out like an ApacheCon CFP and 
submit ideas a minute before the deadline.

Chris

From: Dirk-Willem van Gulik 
Date: Thursday, 27. October 2022 at 10:24
To: dev@community.apache.org 
Subject: Re: European Commission Workshop day on Open-Source Sustainability
I've been in touch with the various organizers (who do not seem to be that 
organised).

Happy to bundle things once we reach some sort of conclusion here. But suspect 
we need to do this in the next hours and days; not week.

That said - these meetings are open - so anyone can 'show up' and participate. 
In many ways this type of meeting where the EC tries to inform itself are very 
much in a spirit akin to open source; just show up, contribute meaningfully, 
constructively and have knowledge/information to bring.

Dw

> On 26 Oct 2022, at 23:14, Jarek Potiuk  wrote:
>
> Do you have a specific contact or conversation you can forward? Or is
> it a generic address we should find ourselves?
>
> On Wed, Oct 26, 2022 at 10:55 PM Christofer Dutz
>  wrote:
>>
>> Hi all,
>>
>> I think we probably should at least tell them as soon as possible, that we 
>> want to attend and which seessions, which people would be willing to 
>> participate.
>>
>> As I mentioned, unfortunately I won’t be able to attend.
>>
>> Chris
>>
>>
>> From: Jean-Baptiste Onofré 
>> Date: Wednesday, 26. October 2022 at 19:42
>> To: dev@community.apache.org 
>> Subject: Re: European Commission Workshop day on Open-Source Sustainability
>> Hi Chris,
>>
>> I can be there as well if needed.
>>
>> Regards
>> JB
>>
>> On Tue, Oct 25, 2022 at 10:44 AM Christofer Dutz
>>  wrote:
>>>
>>> Hi all,
>>>
>>> as I attended the last set of workshops in pre-pandemic times, it seems the 
>>> European Commission is continuing to try to understand open-source.
>>> In this quest it seems they are planning on doing a set of workshops on a 
>>> one-day session:
>>> https://swforum.eu/events/open-source-workshops-computing-sustainability
>>>
>>> As last time Willem and I traveled there as we didn’t want the corporates 
>>> to take over the narrative and explain to the European commission how 
>>> Open-Source works, perhaps we should participate.
>>> I mean … we’re a pretty important factor in open-source, I guess.
>>>
>>> What do you folks 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: European Commission Workshop day on Open-Source Sustainability

[Christofer Dutz]

Well I thought we would coordinate things a bit more here and then I could 
forward it as bulk to them. Didn't think everyone contacting them on his own 
was what they would expect.

Chris

Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>

From: Jarek Potiuk 
Sent: Wednesday, October 26, 2022 11:14:13 PM
To: dev@community.apache.org 
Subject: Re: European Commission Workshop day on Open-Source Sustainability

Do you have a specific contact or conversation you can forward? Or is
it a generic address we should find ourselves?

On Wed, Oct 26, 2022 at 10:55 PM Christofer Dutz
 wrote:
>
> Hi all,
>
> I think we probably should at least tell them as soon as possible, that we 
> want to attend and which seessions, which people would be willing to 
> participate.
>
> As I mentioned, unfortunately I won’t be able to attend.
>
> Chris
>
>
> From: Jean-Baptiste Onofré 
> Date: Wednesday, 26. October 2022 at 19:42
> To: dev@community.apache.org 
> Subject: Re: European Commission Workshop day on Open-Source Sustainability
> Hi Chris,
>
> I can be there as well if needed.
>
> Regards
> JB
>
> On Tue, Oct 25, 2022 at 10:44 AM Christofer Dutz
>  wrote:
> >
> > Hi all,
> >
> > as I attended the last set of workshops in pre-pandemic times, it seems the 
> > European Commission is continuing to try to understand open-source.
> > In this quest it seems they are planning on doing a set of workshops on a 
> > one-day session:
> > https://swforum.eu/events/open-source-workshops-computing-sustainability
> >
> > As last time Willem and I traveled there as we didn’t want the corporates 
> > to take over the narrative and explain to the European commission how 
> > Open-Source works, perhaps we should participate.
> > I mean … we’re a pretty important factor in open-source, I guess.
> >
> > What do you folks 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: European Commission Workshop day on Open-Source Sustainability

[Christofer Dutz]

Hi all,

I think we probably should at least tell them as soon as possible, that we want 
to attend and which seessions, which people would be willing to participate.

As I mentioned, unfortunately I won’t be able to attend.

Chris


From: Jean-Baptiste Onofré 
Date: Wednesday, 26. October 2022 at 19:42
To: dev@community.apache.org 
Subject: Re: European Commission Workshop day on Open-Source Sustainability
Hi Chris,

I can be there as well if needed.

Regards
JB

On Tue, Oct 25, 2022 at 10:44 AM Christofer Dutz
 wrote:
>
> Hi all,
>
> as I attended the last set of workshops in pre-pandemic times, it seems the 
> European Commission is continuing to try to understand open-source.
> In this quest it seems they are planning on doing a set of workshops on a 
> one-day session:
> https://swforum.eu/events/open-source-workshops-computing-sustainability
>
> As last time Willem and I traveled there as we didn’t want the corporates to 
> take over the narrative and explain to the European commission how 
> Open-Source works, perhaps we should participate.
> I mean … we’re a pretty important factor in open-source, I guess.
>
> What do you folks think?
>
> Chris

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

Re: European Commission Workshop day on Open-Source Sustainability

[Christofer Dutz]

Hi all,

Unfortunately, I won’t be able to go, but I wanted to make sure we are aware 
and possibly able to participate.

However, I contacted them for more information, as some of the topics seem 
somewhat finished and some don’t.

Here’s what I got in response: “The workshops will consist in a panel but there 
will be time for having a vivid discussion between all participants. Note that 
the workshops are targeted to specific policy areas. Not all lists of panelists 
are finalised and that is the reason why they are not yet published. In case 
you are interested in participating in a particular panel, feel free to 
communicate your interest and reasons and we will put through the information 
to the panel organizer.”

So there still seems to be the possibility to participate in some of the panel 
discussions as panelists.
But I think we should probably be as quickly as possible with sending them 
proposals.

Chris



From: Dirk-Willem van Gulik 
Date: Tuesday, 25. October 2022 at 11:29
To: dev@community.apache.org , Christofer Dutz 

Subject: Re: European Commission Workshop day on Open-Source Sustainability
On 25 Oct 2022, at 10:44, Christofer Dutz  wrote:

> as I attended the last set of workshops in pre-pandemic times, it seems the 
> European Commission is continuing to try to understand open-source.
> In this quest it seems they are planning on doing a set of workshops on a 
> one-day session:
> https://swforum.eu/events/open-source-workshops-computing-sustainability

I should be going there.

> As last time Willem and I traveled there as we didn’t want the corporates to 
> take over the narrative and explain to the European commission how 
> Open-Source works, perhaps we should participate.
> I mean … we’re a pretty important factor in open-source, I guess.

Not just that - but open source is becoming key to society; the the 
infrastructure of our economie, our society, and so on.

Would be useful to prepare prior with those that intent to go. As these 
meetings are slowly moving from 'understanding' to 'how is, (and will) this 
industry regulate itself' to, if it is not, `what regulation would potentially 
work (to help shape society the way the EU generally sees society)'.

Happy to help coordinate,

With kind regards,

Dw

European Commission Workshop day on Open-Source Sustainability

[Christofer Dutz]

Hi all,

as I attended the last set of workshops in pre-pandemic times, it seems the 
European Commission is continuing to try to understand open-source.
In this quest it seems they are planning on doing a set of workshops on a 
one-day session:
https://swforum.eu/events/open-source-workshops-computing-sustainability

As last time Willem and I traveled there as we didn’t want the corporates to 
take over the narrative and explain to the European commission how Open-Source 
works, perhaps we should participate.
I mean … we’re a pretty important factor in open-source, I guess.

What do you folks think?

Chris

Re: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

; > build the leads and they can get bigger revenue with bigger probability.
> > So
> > > effectively - they will de-priorise such small "slim chance of revenue"
> > > projects and will be working mostly on the big ones ("better chance of
> > > revenue"). Which I think is the opposite you wanted to achieve.
> > >
> > > Also you have to remember this approach does not scale. If you have
> > > multiple different projects, you have no economy of scale - different
> > > stakeholders, different leads, diffferent things to learn (and take time
> > > of) from PMC members. The "sales" process is much more about "who you
> > know"
> > > than "what and how you do" and it does not scale well if you have
> > different
> > > groups of people "to know".
> > >
> > > But (and again this is my experiences and others might vary) the
> > > administrative stuff (invoicing/legal/contracts) is something that:
> > >
> > > a) takes awfully lot of time energy and brings a lot of frustration
> > > (especially when dealing with big customers)
> > > b) could be easily outsourced
> > > c) has a very straightforward and cheap business model (USD 5 /
> > > Invoice/Transfer for example)
> > > d) but if done at scale can help both big and small projects alike - and
> > > cut a lot of time/overhead that otherwise would be almost imposible for
> > > small projects to overcome
> > > e) scales beautfully if there might be one legal entity covering many
> > > projects
> > >
> > > Just to give an example - it took 6 months(!) for my "self-employed"
> > > company to be registered as Google Contractor. Then after I invoiced my
> > > first involce and Google changed Business Entity from Ireland to Poland
> > and
> > > it took another 3 months to move my company from one to the other. During
> > > the 6 months I could not get paid (I luckily had another source of income
> > > as smaller companies at startup stage act faster). During the 3 month of
> > > transition I did not issue invoices (nor get paid) and after 3 months it
> > > took me 2 months of iterations and sending about 10 different invoices
> > > until we managed to work out how I should "really" invoice I should issue
> > > so that it is in-line with the rules (which I was of course not aware
> > of).
> > > That took enormous and needles amount of time and energy and brought a
> > lot
> > > of frustration. T\his could have been avoided if someone - much better in
> > > accounting than me - could take care about it.
> > >
> > > And I simply could afford to wait as I had other sources of income.
> > >
> > > Another example - I spent a small fortune with my lawyers iterating on a
> > > contract that would be good for me (as the customer asked me to provide
> > > one). After I did and send it, after two weeks ... I got the customer's
> > > contract proposal which had nothing to do with my proposal. I think I
> > > already paid more to my lawyers for the preparation of the contract than
> > I
> > > will earn from the contract in 3-4 months. I did it smartly and I
> > prepared
> > > the contract in smart enough way so that I can use it as a template for
> > my
> > > future customers, but still - not having to do it (including time lost
> > and
> > > energy and frustration) would be a blessing. And this scales wel (if
> > > possible,. I am actually planning to donate my contract template to
> > others
> > > at ASF as I specifically put there some clauses that protected my status
> > as
> > > an idependent contributor).
> > >
> > > That's why I - personally -  think trying to build a company that will
> > > "market" and "sale" your jobs is not the right goal but making a
> > machinery
> > > that wil allow other contributors to make use of them easily is much more
> > > important. But I might be biased of course - maybe I am just totally
> > wrong
> > > on that. I would not like to take the energy off such initiative if
> > someone
> > > wants to try it differently - those are just my personal experiences
> > that I
> > > wanted to share.
> > >
> > > J.
> > >
> > >
> > >
> > >
> > >> On Tue, May 10, 2022 at 2:02 PM Christofer Dutz <
> > christofer.d...@c-ware.de>
> > >> 

Re: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

These were the parts, that I was thinking should be the work of such a shared 
Support Inc. That the projects could concentrate on the work, not on what's 
needed to get the work.

Chris

Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>

From: Matt Sicker 
Sent: Monday, May 9, 2022 6:35:06 PM
To: dev@community.apache.org 
Subject: Re: [DISCUSS] Crazy or good Idea?

So let's look at this from the point of view of a small PMC here, say
any of those that have less than 10 committers or so still around
(possibly even with only 3 active PMC members). I don't see how asking
an already overburdened project to bootstrap their own ability to work
on the project fulltime by adding marketing, sales, client relations,
and other business needs, will end up helping any PMC other than those
who already have companies sponsoring development. Simply look at the
various states of what each PMC's website looks like, and you can
probably figure out which PMCs would still be highly unlikely to be
able to market themselves.

On Mon, May 9, 2022 at 11:10 AM Jarek Potiuk  wrote:
>
> Worth checking.
>
> Seems to be possible for other non-profits with the same regime (see the
> list of the hosts there).
>
> I think the big difference here is not that the ASF points to
> OpenCollective, but that Open Collective points to ASF as the "host" and
> the PMC initiatives point to ASF as "host" when they join open collective -
> not the other way round. ASF barely accepts those initiatives to use their
> legal entity for invoicing (at least that's how I see it, probably there
> are some implications involving responsibilities).
>
> That makes a whole world of difference because ASF is pretty passively
> involved in this relation, not actively promoting anyone except of doing
> the invoicing and handling payments (which I think is perfectly fine with
> the non-profit status of it as ASF does a lot of invoicing already).
>
> On Mon, May 9, 2022 at 6:01 PM Christofer Dutz 
> wrote:
>
> > Hi Jarek,
> >
> > But I still can't believe this could be legal for the ASF to do. I would
> > love it to be ok, but right now it's even problematic to even have links to
> > commercial offerings regarding Apache projects, because that would endanger
> > our non-profit status. I just can't believe something like this could even
> > be possible.
> >
> > Chris
> >
> > -Original Message-
> > From: Jarek Potiuk 
> > Sent: Montag, 9. Mai 2022 17:53
> > To: dev@community.apache.org
> > Subject: Re: [DISCUSS] Crazy or good Idea?
> >
> > And a comment  - if, and only if ASF could become the Fiscal Host for all
> > those initiatives and it would be legal from the point of view of the
> > bylaws of the Foundation, this concern of yours Chris should be
> > automatically handled:
> >
> > > I mean with most companies in the Industry, they only work with
> > > preferred
> > vendors and they have a limited amount of “slots” on that list. So, they
> > usually have business relationships with the bigger companies. If we don’t
> > have a good open-source Support Inc. able to fill one of these slots, it
> > doesn’t matter how many there are.
> >
> > The invoicing would be directly with the ASF - even though ASF would not
> > be "owning" the relationship. Yeah. That precludes any "Agreement" with the
> > ASF, but maybe there are a number of companies that would be open to the
> > approach that they are supporting an initiative from a PMC but the invoice
> > goes to the ASF. This is even better that a separate legal entity with ASF
> > blessing (but of course there are many legal/responsibility etc.
> > questions such setup involves - which is more on the legal side).
> >
> > J.
> >
> >
> > On Mon, May 9, 2022 at 5:43 PM Jarek Potiuk  wrote:
> >
> > > > What does it mean to “enable” marketing? If that’s the same level of
> > > marketing we get at the ASF already, then it’s dead in the water for
> > > most projects.
> > >
> > > The best is to show an example here.
> > >
> > > This is the initiative I recently supported
> > > https://opencollective.com/devfest-for-ukraine/ (And I heartily
> > > recommend it - I know the organizers and they are very legit).
> > >
> > > "Enable marketing" in the sense that OpenCollective pre-vets their
> > > collectives and you can market it yourself via social media and other
> > > channels and it is not a scam. I think anyone running any kind of
> > > collective like that (including PMCs a

RE: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

Hi Jarek,

But I still can't believe this could be legal for the ASF to do. I would love 
it to be ok, but right now it's even problematic to even have links to 
commercial offerings regarding Apache projects, because that would endanger our 
non-profit status. I just can't believe something like this could even be 
possible.

Chris

-Original Message-
From: Jarek Potiuk  
Sent: Montag, 9. Mai 2022 17:53
To: dev@community.apache.org
Subject: Re: [DISCUSS] Crazy or good Idea?

And a comment  - if, and only if ASF could become the Fiscal Host for all those 
initiatives and it would be legal from the point of view of the bylaws of the 
Foundation, this concern of yours Chris should be automatically handled:

> I mean with most companies in the Industry, they only work with 
> preferred
vendors and they have a limited amount of “slots” on that list. So, they 
usually have business relationships with the bigger companies. If we don’t have 
a good open-source Support Inc. able to fill one of these slots, it doesn’t 
matter how many there are.

The invoicing would be directly with the ASF - even though ASF would not be 
"owning" the relationship. Yeah. That precludes any "Agreement" with the ASF, 
but maybe there are a number of companies that would be open to the approach 
that they are supporting an initiative from a PMC but the invoice goes to the 
ASF. This is even better that a separate legal entity with ASF blessing (but of 
course there are many legal/responsibility etc.
questions such setup involves - which is more on the legal side).

J.


On Mon, May 9, 2022 at 5:43 PM Jarek Potiuk  wrote:

> > What does it mean to “enable” marketing? If that’s the same level of
> marketing we get at the ASF already, then it’s dead in the water for 
> most projects.
>
> The best is to show an example here.
>
> This is the initiative I recently supported 
> https://opencollective.com/devfest-for-ukraine/ (And I heartily 
> recommend it - I know the organizers and they are very legit).
>
> "Enable marketing" in the sense that OpenCollective pre-vets their 
> collectives and you can market it yourself via social media and other 
> channels and it is not a scam. I think anyone running any kind of 
> collective like that (including PMCs and others) are responsible for 
> their own marketing, using the networking, social media, tools, direct 
> outreach etc. Expecting that someone will do it for you is not going to work.
>
> Having a landing page like that which is hosted with a reputable 
> organisation that pre-vets their campaigns and one that you can see 
> who the people are, you can see who else is supporting it is a 
> fantastic marketing tool that you can use. And this is really good 
> value that such organisations can bring.
>
> J.
>
>
>
> On Mon, May 9, 2022 at 5:28 PM Matt Sicker  wrote:
>
>> What does it mean to “enable” marketing? If that’s the same level of 
>> marketing we get at the ASF already, then it’s dead in the water for 
>> most projects.
>>
>> —
>> Matt Sicker
>>
>> > On May 9, 2022, at 10:22, Jarek Potiuk  wrote:
>> >
>> > 
>> >>
>> >> I think the non-profit charity aspect definitely would disqualify 
>> >> the
>> ASF
>> > as being one of these Fiscal Hosts. But in general, it does sound 
>> > like
>> they
>> > could be something usable, just not using the ASF as Fiscal Host.
>> >
>> > I am not sure to be honest. From at least looking at the 
>> > description of what Fiscal Host is, this is mainly about "legal 
>> > entity", "being able to issue invoices" and that's about it.
>> >
>> > Even if you look at the fiscal hosts that the open-collective 
>> > manages,
>> they
>> > have a 501(C) US-Based charity foundation as one of the fiscal hosts:
>> > https://opencollective.com/foundation  - which I think is the same
>> regime
>> > as the ASF.
>> >
>> > See:
>> > https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts
>> >
>> >> On Mon, May 9, 2022 at 5:11 PM Christofer Dutz <
>> christofer.d...@c-ware.de>
>> >> wrote:
>> >>
>> >> Hi Roman and Jarek,
>> >>
>> >> well the reason I was proposing something new was that I did try 
>> >> to participate with some of the existing initiatives like 
>> >> Tidelift, but
>> they
>> >> showed a great amount of disinterest. It seems as if only the 
>> >> projects
>> big
>> >> enough are considered worthy of being supported. The entity I 
>> >> proposed should be av

RE: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

apply" to be hosted by a fiscal host. I am not sure what are the rules and 
policies there, but I believe the collectives have to be "approved" by the ASF 
host. And this is as close to "endorsement" without actually a legal 
responsibility as it can be. The "sponsors" would deal with the ASF that would 
issue the invoices, while the "business relationship" of Sponsor will be with 
the collective organizers.

This really sounds rather cool if we could make ASF become such a Fiscal Host.

Few claims they do:

* "Unlike other crowdfunding platforms, Open Collective is designed for ongoing 
collaborations. That means your funding and community of support doesn’t 
disappear after a single campaign, or if the initial organizers move on.
* "Our code is fully transparent and open source, just like our budget. You own 
your data: we’ll never sell it or lock you in."
* "Open Collective uniquely combines a powerful tech platform with fiscal 
hosting, enabling Collectives to raise and spend money without legally 
incorporating, worrying about taxes, or opening a bank account."

J.

On Mon, May 9, 2022 at 11:16 AM Roman Shaposhnik 
wrote:

> Chris, thanks for sort of reviving the old thread I had before the
> war: I'm slowly coming back to my more regular Open Source life from
> all the craziness of the past two months. Because of that, there's not
> much to report back -- but I will share a few points and comment on a
> few of yours. Hope this will help move things along.
>
> On Wed, Apr 20, 2022 at 3:11 PM Christofer Dutz
>  wrote:
> >
> > Hi all,
> >
> > now that the Aprils Fool Joke has worn off a bit, I think I can post
> this here. I at first suggested this in the board list before April
> 1st, as I wanted to make sure this hasn’t been wiped off the table as
> a silly idea before.
> >
> > Turns out that I didn’t get a single “silly idea” response.
> >
> > As you all might know I have been working on finding ways to finance
> > my
> work on open-source, but in an open-source way that others can also
> profit from what I might find out.
> >
> > There are some projects that managed to form or attract companies to
> grow around them. These usually don’t have problems finding funds to
> finance further development.
> > However, we also have a large number of projects that are not as
> > big, or
> a large number of people working on our projects, but don’t work for
> those companies.
> >
> > So, these people are generally relying on finding contracts themselves.
> This usually is problematic as many larger companies don’t do business
> with individuals.
> > Also is it often tricky to get the legal documents and contracts
> > right
> and then not even talking about how long payments usually take.
> >
> > Another thing is that the ASF is a non-profit organization and
> > therefore
> it’s challenging to advertise commercial offerings around Apache projects.
> >
> > As an example: One of the things I found out with my crowd-funding
> experiment is that this doesn’t work. Admittedly I wasn’t expecting it
> to work. Companies just can’t donate large amounts of money without
> any assurances. But I did learn one thing: My crowd-funding experiment
> was in a way the most successful thing I did.
> >
> > The thing was, that I listed up things that could be on the roadmap
> > and
> I added a price-tag to them. This is one thing an Apache project just
> couldn’t do. So even if I didn’t get a single cent in donations for my
> work, I was approached by multiple companies willing to finance
> individual campaigns, but with a normal consulting contract.
> >
> > Now there are also companies like Tidelift, that want to close this gap.
> However, we are still a bit unsure how to align the interest of that
> company with the values of the ASF. And there’s the fact that not
> everyone is able to profit from Tidelift. I for example tried reaching
> out to them several times for offering commercial PLC4X support, but
> the only responses I got, were people wanting to discuss how my
> business could profit from using more open-source ;-) So for me
> Tidelift is not an option as not everyone can use it.
> >
> > Now let me get to my idea:
> > What If there was a separate legal entity closely related to the ASF
> (Let’s call it “Support Inc.” for now). I would even propose that the
> oversight entity for Support Inc. should be the ASF board. This would
> assure the company is perfectly in-line with the ASF and its values.
>
> First of all, I 100% agree with Sam -- there's absolutely 0 reason
> that I see these two entities should have (structurally!) any more
> ties than ASF and let's sa

RE: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

And I think when adding the two fields, we could eliminate question Q5 and Q6.

I saw you extended the table to the bottom to allow me so select something in 
both columns ;-) 

Chris

-Original Message-
From: Christofer Dutz  
Sent: Mittwoch, 27. April 2022 10:34
To: dev@community.apache.org
Subject: RE: [DISCUSS] Crazy or good Idea?

Hi All,

I think I commented in the document ... I think two numeric fields: How many 
hours per week to you work on open-source "paid" and "unpaid" would allow not 
only the type of evaluation regardings the gender distribution, but also would 
allow non-dei related analysis.

Chris

-Original Message-
From: Katia Rojas 
Sent: Dienstag, 26. April 2022 20:09
To: Jarek Potiuk 
Cc: dev@community.apache.org
Subject: Re: [DISCUSS] Crazy or good Idea?

Hello Jarek,

Those are very good questions.
Based on those questions we are assessing the following topics:

1.  Which percentage of the Paid/Unpaid belongs to each gender? It could be 
interesting and potentially actionable if we see a ratio mismatch between paid 
/ unpaid.

2. How would this information help with contributor experience improvement?

3. Could we summarise the questions in one or two questions, open or closed?

We are following up on those topics in the slack channel and the google docs as 
well.

Thanks,
Katia


On Mon, Apr 25, 2022 at 11:13 AM Jarek Potiuk  wrote:

> Hello everyone,
>
> I think we have a great opportunity to get much more insight on what 
> is really needed here.
>
> Katia and the Diversity team are running the 2022 Survey about the 
> contributor's and there was already a question about whether people 
> are being paid/ not paid / mixed.
>
> I think - since this is an important topic - we should gather a bit 
> more stats on what the contributor source of paid work is and what are 
> the biggest obstacles they face in case they want to be paid. I have a 
> feeling that all of us are looking at that from their personal 
> experience and perspectives, but this might vary wildly and the survey 
> seems to be a perfect opportunity to find out more.
>
> The announcement is here and Katia asked for comments till 29th of 
> April - so we have still 3 days:
> https://lists.apache.org/thread/8r0gmw5f10r16drwc5wnyvgvppq3cbcw
>
> I already added a comment describing my ideas for the survey
> questions:
> https://docs.google.com/document/d/1s0TVBFf-KvOTl3IejI2FFOOTdkugZlX_pt
> nN6YWMFN0/edit?disco=YgvywxI
>
> But maybe others could contribute (and even review the survey in 
> general and make more comments) ?
>
> J.
>
>
>
> On Fri, Apr 22, 2022 at 8:33 AM Christofer Dutz 
>  wrote:
> >
> > Yeah,
> >
> > That's exactly what I wanted to address. The bootstrapping: creating
> contacts for the different types of services (legal) , setup and run 
> the infrastructure to serve the offers I want to do and keep them 
> updated and patched (infrastructure), handling payments and chacing 
> after companies not willing to pay (finance), establish a place people 
> know to offer the services (marketing and pr) (this is probably the 
> thing requiring most
> work) and something to not appear to be a solo fighter, but be part of 
> something bigger.
> >
> > I for my part have invested a big part of my last years on all of this.
> In the end I failed mainly because my company is too small and can't 
> compete with the big closed-source names. Now I'm planning on ending 
> my business after 24 years, as I'm tired of fighting.
> >
> > But I would hate to see others in the same situation, so I would 
> > love to
> help others be successful. If what I learned the hard way helps, 
> that's the open-source idea on a next level. And I think something 
> like what I proposed would probably be the thing I personally would 
> have loved to have had and I probably would still be fully 
> self-employed, if such a thing existed.
> >
> > Thinking of my green energy supplier: when I saw the certificate of
> approval, that Greenpeace attests them serving truly green energy, 
> that convinced me to choose them. Perhaps some form of "Apache 
> approves the way this thing works"-certificate that needs to be 
> renewed (yearly), could be a form to do this without any problematic ties?
> >
> >
> > Chris
> >
> > Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
> >
> > 
> > Von: Matt Sicker 
> > Gesendet: Donnerstag, 21. April 2022, 19:50
> > An: dev@community.apache.org 
> > Betreff: Re: [DISCUSS] Crazy or good Idea?
> >
> > On Wed, Apr 20, 2022 at 9:08 AM Jarek Potiuk  wrote:
> > > ... (snip)
> > > This is a model similar to m

RE: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

Hi All,

I think I commented in the document ... I think two numeric fields: How many 
hours per week to you work on open-source "paid" and "unpaid" would allow not 
only the type of evaluation regardings the gender distribution, but also would 
allow non-dei related analysis.

Chris

-Original Message-
From: Katia Rojas  
Sent: Dienstag, 26. April 2022 20:09
To: Jarek Potiuk 
Cc: dev@community.apache.org
Subject: Re: [DISCUSS] Crazy or good Idea?

Hello Jarek,

Those are very good questions.
Based on those questions we are assessing the following topics:

1.  Which percentage of the Paid/Unpaid belongs to each gender? It could be 
interesting and potentially actionable if we see a ratio mismatch between paid 
/ unpaid.

2. How would this information help with contributor experience improvement?

3. Could we summarise the questions in one or two questions, open or closed?

We are following up on those topics in the slack channel and the google docs as 
well.

Thanks,
Katia


On Mon, Apr 25, 2022 at 11:13 AM Jarek Potiuk  wrote:

> Hello everyone,
>
> I think we have a great opportunity to get much more insight on what 
> is really needed here.
>
> Katia and the Diversity team are running the 2022 Survey about the 
> contributor's and there was already a question about whether people 
> are being paid/ not paid / mixed.
>
> I think - since this is an important topic - we should gather a bit 
> more stats on what the contributor source of paid work is and what are 
> the biggest obstacles they face in case they want to be paid. I have a 
> feeling that all of us are looking at that from their personal 
> experience and perspectives, but this might vary wildly and the survey 
> seems to be a perfect opportunity to find out more.
>
> The announcement is here and Katia asked for comments till 29th of 
> April - so we have still 3 days:
> https://lists.apache.org/thread/8r0gmw5f10r16drwc5wnyvgvppq3cbcw
>
> I already added a comment describing my ideas for the survey
> questions:
> https://docs.google.com/document/d/1s0TVBFf-KvOTl3IejI2FFOOTdkugZlX_pt
> nN6YWMFN0/edit?disco=YgvywxI
>
> But maybe others could contribute (and even review the survey in 
> general and make more comments) ?
>
> J.
>
>
>
> On Fri, Apr 22, 2022 at 8:33 AM Christofer Dutz 
>  wrote:
> >
> > Yeah,
> >
> > That's exactly what I wanted to address. The bootstrapping: creating
> contacts for the different types of services (legal) , setup and run 
> the infrastructure to serve the offers I want to do and keep them 
> updated and patched (infrastructure), handling payments and chacing 
> after companies not willing to pay (finance), establish a place people 
> know to offer the services (marketing and pr) (this is probably the 
> thing requiring most
> work) and something to not appear to be a solo fighter, but be part of 
> something bigger.
> >
> > I for my part have invested a big part of my last years on all of this.
> In the end I failed mainly because my company is too small and can't 
> compete with the big closed-source names. Now I'm planning on ending 
> my business after 24 years, as I'm tired of fighting.
> >
> > But I would hate to see others in the same situation, so I would 
> > love to
> help others be successful. If what I learned the hard way helps, 
> that's the open-source idea on a next level. And I think something 
> like what I proposed would probably be the thing I personally would 
> have loved to have had and I probably would still be fully 
> self-employed, if such a thing existed.
> >
> > Thinking of my green energy supplier: when I saw the certificate of
> approval, that Greenpeace attests them serving truly green energy, 
> that convinced me to choose them. Perhaps some form of "Apache 
> approves the way this thing works"-certificate that needs to be 
> renewed (yearly), could be a form to do this without any problematic ties?
> >
> >
> > Chris
> >
> > Holen Sie sich Outlook für Android<https://aka.ms/AAb9ysg>
> >
> > 
> > Von: Matt Sicker 
> > Gesendet: Donnerstag, 21. April 2022, 19:50
> > An: dev@community.apache.org 
> > Betreff: Re: [DISCUSS] Crazy or good Idea?
> >
> > On Wed, Apr 20, 2022 at 9:08 AM Jarek Potiuk  wrote:
> > > ... (snip)
> > > This is a model similar to many ASF projects commercial activities 
> > > - there are people, individuals with merit and experience in the 
> > > project and they decide to start or join a commercial company that 
> > > puts their stakes with the project. There are many stories like 
> > > that and even if some of the people are PMC

Re: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

Yeah,

That's exactly what I wanted to address. The bootstrapping: creating contacts 
for the different types of services (legal) , setup and run the infrastructure 
to serve the offers I want to do and keep them updated and patched 
(infrastructure), handling payments and chacing after companies not willing to 
pay (finance), establish a place people know to offer the services (marketing 
and pr) (this is probably the thing requiring most work) and something to not 
appear to be a solo fighter, but be part of something bigger.

I for my part have invested a big part of my last years on all of this. In the 
end I failed mainly because my company is too small and can't compete with the 
big closed-source names. Now I'm planning on ending my business after 24 years, 
as I'm tired of fighting.

But I would hate to see others in the same situation, so I would love to help 
others be successful. If what I learned the hard way helps, that's the 
open-source idea on a next level. And I think something like what I proposed 
would probably be the thing I personally would have loved to have had and I 
probably would still be fully self-employed, if such a thing existed.

Thinking of my green energy supplier: when I saw the certificate of approval, 
that Greenpeace attests them serving truly green energy, that convinced me to 
choose them. Perhaps some form of "Apache approves the way this thing 
works"-certificate that needs to be renewed (yearly), could be a form to do 
this without any problematic ties?


Chris

Holen Sie sich Outlook für Android


Von: Matt Sicker 
Gesendet: Donnerstag, 21. April 2022, 19:50
An: dev@community.apache.org 
Betreff: Re: [DISCUSS] Crazy or good Idea?

On Wed, Apr 20, 2022 at 9:08 AM Jarek Potiuk  wrote:
> ... (snip)
> This is a model similar to many ASF projects commercial activities -
> there are people, individuals with merit and experience in the project
> and they decide to start or join a commercial company that puts their
> stakes with the project. There are many stories like that and even if
> some of the people are PMC members and committers that might work.
> I see that it could work here as well. I think it is important to see
> if there can be a real business model behind it. On top of doing "good
> support" for the contributors, such a company would have to simply
> have some business model and be a normal "business" I think.

I think I get your point here, though this sort of feels like punting
the idea back to "figure out how to be an Influencer® on your own!" As
a software engineer (particularly in the domain of software
development software itself), I find it much easier to write code,
design systems, fix bugs, and other daily work I'm already used to
performing as an individual contributor at any company. Having all the
other skills necessary to run a business has never really been
interesting to me (and I assume similarly for many others), so such an
approach feels somewhat like trying to make it big on the 'gram or the
'tok (i.e., marketing, publicity, PR, copywriting, artwork, etc.,
either provided by yourself or paid for by someone else as a
"sponsor").

Christofer's proposal sounds more like a way to try to bootstrap past
that issue, though I can see why it would be fairly difficult to align
with the ASF's values of vendor independence. Maybe there's some sort
of hybrid approach possible similar to ALCs where a sort of business
development kit is provided for people to more easily create firms for
development et al.

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

[Christofer Dutz]

Hi all,

I agree that the ASF doesn't have to allow such a Support Inc. thing. However, 
if it officially supported it or even stated that it's fine with the way it 
operates that could be a benefit for Support Inc. being accepted.

Of course, would this be a company with paid staff, therefore people doing 
business through it, definitely will have to pay a certain low percentage or a 
fixed amount for contracts going through it. I'd even suggest that excess 
earnings could flow back to the ASF as donations.

Also, would I think the core purpose of this Support Inc should be to help 
provide a sustainable income for individuals or small businesses that work in 
Open-Source and not to become the next unicorn, that brings millions of dollars 
to its shareholders pockets. I bet a company known for operating this way would 
have a plus on the marketing side. I at least would rather hire a company that 
I know the money flows back into the people behind the projects than into the 
pockets of shareholders.

Initially I even thought this might be something we could use part of that 
500k$ donation for, which should be targeted at creating an endowment. I know 
we're currently struggling with this a bit, but I have no idea if the ASF would 
be allowed to do such a move. So perhaps a Support Endowment might be an option?

Chris


-Original Message-
From: Sam Ruby  
Sent: Mittwoch, 20. April 2022 21:31
To: Apache Community Dev 
Subject: Re: [DISCUSS] Crazy or good Idea?

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

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.

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.

- 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

RE: [DISCUSS] Crazy or good Idea?

[Christofer Dutz]

Hi all,

well in general the only reason I added the Board oversight into my sketch was 
because I've seen with other companies (Like Tidelift) that this is the main 
problem when it comes to working together with the ASF Projects. So I thought: 
If the board is added as an oversight, then we can ensure that the companies 
goals don't cannibalize the ASF's goals.

I'm definitely not insisting on this ... I would just hate to see yet another 
commercial entity that is not in line with the ASF emerge.

Also, would I like to lay emphasis on the part of everyone being able to be 
registered. Of course, can't we provide 24/7 instant support for all projects, 
the Support Inc. would more act as a proxy between individuals (Or even groups 
of individuals).

Chris

-Original Message-
From: giova...@paclan.it  
Sent: Mittwoch, 20. April 2022 16:45
To: dev@community.apache.org
Subject: Re: [DISCUSS] Crazy or good Idea?

I like the idea a lot and, actually, I thought about something similar (more 
similar to Jarek's interpretation) more then once but I always stopped by 
thinking "who should be crazy enough to support this ?".
Probably now times are mature enough to start something.
 Giovanni 

On 4/20/22 16:07, Jarek Potiuk wrote:
> I like the idea, not silly at all, but I think it has one caveat.
> 
> Contrary to what you wrote about the ASF values, I think (that's my 
> first thought at least) that if it happens it should be an individual 
> initiative of some members. And IMHO there should be no formal 
> board/ASF affiliation IMHO because then it is - at least that's my gut 
> feeling - quite contrary to the values and the ASF legal status.
> 
> As I see it - people representing the Support Inc. company (even if 
> they are from ASF) should not really be "ASF representatives" because 
> if they do, this puts some responsibilities and guarantees on both 
> sides (and especially on the ASF). There are certain guarantees that 
> come with more or less formal association with the ASF brand and I 
> think if the board overlooks the "Support Inc." - by definition it has 
> some guarantees (and I do not know for sure but that would likely not 
> be legal when it comes to the ASF status). But that would not (I
> think) preclude that some of the founders are board members. As long 
> as there is a good care about conflict of interests separation, the 
> multiple-hat idea is quite easy to apply here.
> 
> That would likely make Support Inc. less "attractive" - especially for 
> the potential customers (precisely because of the lack of those 
> guarantees by the ASF). But on the other hand, if this company is run 
> and started by people who are "well established" in the OSS community 
> the attractiveness of such a Support Inc. company is already high. If 
> anything, by the network of individual relations of those people who 
> start it. In a way this would be similar approach as Tidelift (some of 
> the people there are with the OSS background), but it could be 
> structured differently (with different incentivization for both 
> customers and contributors, focusing more on individual relationships 
> of people who would start it rather than on "brand/company", different 
> marketing and promotion ideas - so it could be better suited for the 
> ASF projects. And it could become part of the "ecosystem" around the 
> ASF (which the ASF could actually list on the page among others like 
> Tiidelfit without endorsement or guarantees). So it might be a YABD 
> (Yet Another But Different) Tidelift-like company.
> 
> This is a model similar to many ASF projects commercial activities - 
> there are people, individuals with merit and experience in the project 
> and they decide to start or join a commercial company that puts their 
> stakes with the project. There are many stories like that and even if 
> some of the people are PMC members and committers that might work.
> I see that it could work here as well. I think it is important to see 
> if there can be a real business model behind it. On top of doing "good 
> support" for the contributors, such a company would have to simply 
> have some business model and be a normal "business" I think.
> 
> I am not sure if such an approach is contrary to the idea of yours 
> Chris, or whether this is something that you also considered or 
> whether "non-official-affiliation" is a "killer" in your idea (I hope 
> not :). And I am not 100% sure if my "non-affiliation" is that 
> important. I think it is, but I would love to hear what others and You 
> have to say there.
> 
> J.
> 
> On Wed, Apr 20, 2022 at 2:11 PM Christofer Dutz 
>  wrote:
>>
>> Hi all,
>>
>> now 

[DISCUSS] Crazy or good Idea?

[Christofer Dutz]

Hi all,

now that the Aprils Fool Joke has worn off a bit, I think I can post this here. 
I at first suggested this in the board list before April 1st, as I wanted to 
make sure this hasn’t been wiped off the table as a silly idea before.

Turns out that I didn’t get a single “silly idea” response.

As you all might know I have been working on finding ways to finance my work on 
open-source, but in an open-source way that others can also profit from what I 
might find out.

There are some projects that managed to form or attract companies to grow 
around them. These usually don’t have problems finding funds to finance further 
development.
However, we also have a large number of projects that are not as big, or a 
large number of people working on our projects, but don’t work for those 
companies.

So, these people are generally relying on finding contracts themselves. This 
usually is problematic as many larger companies don’t do business with 
individuals.
Also is it often tricky to get the legal documents and contracts right and then 
not even talking about how long payments usually take.

Another thing is that the ASF is a non-profit organization and therefore it’s 
challenging to advertise commercial offerings around Apache projects.

As an example: One of the things I found out with my crowd-funding experiment 
is that this doesn’t work. Admittedly I wasn’t expecting it to work. Companies 
just can’t donate large amounts of money without any assurances. But I did 
learn one thing: My crowd-funding experiment was in a way the most successful 
thing I did.

The thing was, that I listed up things that could be on the roadmap and I added 
a price-tag to them. This is one thing an Apache project just couldn’t do. So 
even if I didn’t get a single cent in donations for my work, I was approached 
by multiple companies willing to finance individual campaigns, but with a 
normal consulting contract.

Now there are also companies like Tidelift, that want to close this gap. 
However, we are still a bit unsure how to align the interest of that company 
with the values of the ASF. And there’s the fact that not everyone is able to 
profit from Tidelift. I for example tried reaching out to them several times 
for offering commercial PLC4X support, but the only responses I got, were 
people wanting to discuss how my business could profit from using more 
open-source ;-) So for me Tidelift is not an option as not everyone can use it.

Now let me get to my idea:
What If there was a separate legal entity closely related to the ASF (Let’s 
call it “Support Inc.” for now). I would even propose that the oversight entity 
for Support Inc. should be the ASF board. This would assure the company is 
perfectly in-line with the ASF and its values.

Individuals could sign up on Support Inc’s website for providing commercial 
services around Apache projects. These services could be Consulting, Feature 
development, Training, Commercial Support.
On this site a user could also add possible feature-development campaigns with 
a price-tag attached, just like I did on my website.

If a company wants to finance a feature, get support, consulting, or training 
around an Apache project, this would be the well-known website somebody would 
go to first.

Support Inc. would provide the contracts and therefore the individual wouldn’t 
have to (I usually spent 2000-4000€/year on legal advice for stuff like that). 
Also, would Support Inc. be a bigger company the customer would be doing 
business with, which would probably ease the problem of getting into the 
companies with Chris Inc.

The contracts would be between the Support Inc. and the customer, and the 
customer would pay to Support Inc. The developer would have a contract with 
Support Inc. and be paid from this but give Support Inc. a certain percentage 
of the contact to cover its expenses (But in contrast to other pure for-profit 
companies, this cut would be a lot less than usual).
Now a developer could probably choose from different models, where he gets paid 
instantly (but then give Support Inc. a bigger cut of the profits) or wait for 
the customer to pay.
The services the new company would provide, would be taking care of the 
payments, the legal issues and provide the infrastructure for finding 
commercial support offerings.
And if people know this is something integrated into the general open-source 
ecosystem, I assume people would probably try less to screw with as they know 
it might backfire PR-wise, just like dragging the ASF to court wouldn’t be the 
smartest thing to do.

If the company earns money, it could become a sponsor of the ASF.

What do you think?

I hope you’re now not going to point at me laughing because I like the idea.

Chris

Reminder: Apache Training (incubating) is open for all Apache committers

[Christofer Dutz]

Hi all,

I would like to take the chance to bring attention back to the Apache Training 
(incubating) project.
This was initiated to act as a hub to create and share training materials on 
Apache projects (or Apache itself).
We decided last year to give every Apache committer commit rights to our repo.

It would be great if some people would provide some entry level content for 
their projects.

If anyone needs any help with that, the Training IPMC is more than happy to 
help.

Chris

Setting up a (temporary) slack channel for helping ukraine refugees?

[Christofer Dutz]

Hi all,

I just recently gave shelter to a group of 6 refugees from the Ukraine. This 
group consists of:

  *   One mother with two small children (2 and 5)
  *   The grandmother
  *   The "nanny" with her 10-year-old

They have expressed wanting to get a job as soon as possible. As my apartment 
is in Darmstadt, jobs would have to be either close to Darmstadt or remote ones.

The mother seems to have worked as a social media marketing professional with 
photography (products and people) and speaks good English.
The "granny" isn't really close to a pensioner yet and got a degree in Physics 
(Used to teach that) but worked in the logistics of a furniture manufacturer. 
However, she only peaks a little English.
The "nanny" has a degree in Psychology and Psychiatry. However, she also only 
peaks a little English and said she'd love to work as a nurse.

Now I know this is not the mission of the ASF, but the ASF is also a huge 
network of people knowing people and people knowing companies.
So, I thought, wouldn't it be nice to setup a "help-ukraine" slack channel or 
something like that, where people willing to help can quickly exchange?
As soon as this whole thing is over (hopefully sooner than later) we can just 
drop the channel again.

What do you think about the channel ... and does anyone know any job openings 
for these great people?

Chris

RE: Apache Reporter Hangs

[Christofer Dutz]

I can confirm this.

I get a popup with "Notification [object Response]" ... if I close the popup, I 
can watch the bouncy bars for ... probably ever.

Chris

-Original Message-
From: Andrea Cosentino  
Sent: Donnerstag, 3. März 2022 07:30
To: dev@community.apache.org
Subject: Apache Reporter Hangs

Hello,

I just want to make you aware that actually the Apache Reporter Wizard is 
hanging.

https://reporter.apache.org/wizard/

Thanks

-
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

[Christofer Dutz]

Just thinking out loud ...

The ASF could never be an entity that people could come to looking for 
commercial support. 
That would just be in conflict with being a non-profit charitable organization.

However, we also have this discussion about the endowment from the pinaple 
funds donation.
How about having the ASF as it is, was and hopefully will always be, and a 
second entity that people could come to for commercial support.
In contrast to the usual external companies, the board of this entity could be 
linked to the board of the ASF? 
This would ensure that the company is run in line with the values of the ASF.

Please tell me if this is just complete nonsense ;-)

Chris



-Original Message-
From: Dave Fisher  
Sent: Donnerstag, 3. März 2022 07:33
To: dev@community.apache.org
Subject: Re: Effective ways of getting individuals funded to work on ASF 
projects

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

[Christofer Dutz]

Hi all,

As I was confronted with the question of how commercial support or paid feature 
development and Apache would work together. I came up with this way of handling 
it:
If I am offering any form of commercial support or feature development I say: 
"I will fix your problem. The fix then can become part of the open-source 
project, but if the project decides to decline It, I'll make it available to 
you in a fork that I create for you." This should work for Tidelift or any 
similar form of platform too.

Chris

-Original Message-
From: Jim Jagielski  
Sent: Montag, 28. Februar 2022 19:24
To: dev@community.apache.org
Subject: Re: Effective ways of getting individuals funded to work on ASF 
projects

Tidelift's model, which expects that maintainers do have direct and almost 
unassailable control over a project, is not compatible with the Apache Way. 
Tidelift's model works well with projects in which developers and maintainers 
can "do stuff" without worrying about building a consensus around whether or 
not their contributions are OK or not.

I'd like to see how that model and Apache could fit together, but I'm at a loss 
to think about how. The main benefit that those who fund the work is not just 
an expectation that code will be fixed, etc, but a *requirement* that it be 
done. They are paying for the guarantee. This requires a development model in 
which those paid by Tidelift can forcibly introduce code and contributions at 
will. This conflicts with the ASF development model.

> On Feb 28, 2022, at 12:50 PM, Jarek Potiuk  wrote:
> 
>> So while I agree with everything Bertrand said I don’t think it 
>> resolves
> the real issue.
> TideLift is providing a guarantee to its customers that projects it 
> sponsors meet certain standards. The standards they are looking for 
> should really be set by the ASF, not individual projects.
> 
> This is the part I do not understand. What Tidelift can promise to 
> their customers and on what basis?
> According to ASF rules where only individuals in the project can make 
> decisions - this means that Tidelift has no mechanisms whatsoever to 
> fulfill their promise.
> 
> And if ASF sets the standards - why do we need Tidelift at all ?
> To be perfectly blunt -  I am afraid that until Tidelift resolves any 
> of the real problems of individual committers we mentioned with 
> Bertrand (including facilitating direct relationship commiter <> 
> stakeholder), I do not see what's the added value of Tidelift. Seems 
> like unnecessary intermediary.
> 
> J.
> 
> 
> On Mon, Feb 28, 2022 at 5:10 PM Ralph Goers 
> 
> wrote:
> 
>> First, I would like to clarify Gary’s email as I don’t think he 
>> characterized it quite correctly.
>> The Logging PMC concluded we could not be part of an arrangement with 
>> TideLift and that the issues needed to be worked out at the 
>> foundation level. The primary issue was that TideLift had 
>> requirements on advertising and process details that required 
>> approval of the PMC in order for individuals to be able to be paid. 
>> We met with a Google security team in January and had similar issues 
>> where they required a process that isn’t aligned with the ASF’s 
>> requirements on how releases are to be performed.
>> 
>> Second, from my point of view the ASF should have discussions with 
>> TideLift and Google to see if those issues can be resolved. The ideal 
>> scenario would be that TideLift and Google can simply sponsor 
>> individuals from any ASF project because all ASF projects must 
>> conform to guidelines that meet their criteria - i.e. the PMC doesn’t 
>> even have to be involved. But this obviously requires that the 
>> foundation work with these third parties to either improve our 
>> processes where needed or get the third party to accept our 
>> processes.
>> 
>> So while I agree with everything Bertrand said I don’t think it 
>> resolves the real issue.
>> TideLift is providing a guarantee to its customers that projects it 
>> sponsors meet certain standards. The standards they are looking for 
>> should really be set by the ASF, not individual projects.
>> 
>> Ralph
>> 
>> 
>>> On Feb 28, 2022, at 5:03 AM, Bertrand Delacretaz 
>>> 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> Le lun. 28 févr. 2022 à 11:06, Jarek Potiuk  a écrit :
 ...the relationships I have is direct relationship with the 
 stakeholders. Let's deel, GitHub Sponsors, SAP Ariba are merely
>> "removing
 bureaucratic obstacles" but they are not "between" me and my
>> stakeholders.
 They are "on a side". They get a small cut sometimes (which I 
 gladly
>> pay)
 but I want to talk to the stakeholders directly without any
>> intermediaries
 and establish a long-term relationship with them as an individual
>>> 
>>> I think that's a key point, and listing such requirements for 
>>> platforms that can help our contributors get funding sounds useful.
>>> 
>>> Here's a quick list of initial requirements that we might include:
>>> 

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

[Christofer Dutz]

Hi Roman,

thanks for bringing this up here … I too want to help with exactly this. I 
tried starting a discussion on this on members@ but that sort of dried up and 
it felt a bit like a monologue or people simply telling me what didn’t work for 
them in the past and therefore I shouldn’t try on my own … but I keep on adding 
stuff in hope someone might be passively consuming.

For this, in 2021 I invested quite a bit of work, time and even money in 
scouting solutions.

I knew most things I tried, would not be successful, but I wanted to do them to 
see in which way they didn’t perform. And I’m glad I tried it. Because I did 
learn things, that I haven’t thought about before. So let me share this with 
you all. Not all things I learned will apply to all projects and all 
industries. My experience is greatly dominated by automation industry and my 
work on PLC4X.

So initially I tried offering paid consulting, training, and implementation 
work for PLC4X. This failed, mainly because the Automation industry is not used 
to this concept. At least the concept of individual contractors. Most companies 
use Perferred-Vendor approaches. This is the same in more classical 
IT-consulting consuming industries. The main difference however is that in the 
automation industry there are no proxy-companies as there are in the other 
parts of the industry, which individuals could use as proxies. In the past I 
have worked for numerous Banks by offering services through consulting 
companies that were listed as Preferred vendors. Usually even if a bank 
approached me directly, they then said: So, we’re going to take care of setting 
things up with company X, which is in our Preferred vendor-list, … This 
infrastructure is completely missing in the Automation sector.

In order to make it easier for potential customers to find people willing to 
help, we added:
https://plc4x.apache.org/users/commercial-support.html
To the Apache PLC4X website. This was a bit tricky to get right, but I think in 
the end we got it into a form that is in-line with the ASF and what we are 
allowed to do as a non-profit charity.

In parallel I took every chance to speak at conferences or publish in 
tech-magazines. However, our potential customers simply didn’t go to those 
conferences or read those magazines. The automation industry has industrial 
fairs instead of conferences and their magazines are all pay to play. So, you 
need to invest a lot of money to be noticed. This is 100% in conflict with the 
ASF’s mission, and I don’t really see any way how we can change this, unless 
companies are willing to sponsor Open-Source (and ASF) content or give us some 
space at industrial fairs. I definitely don’t see the ASF using it’s budget for 
that, unless it’s a targeted donation explicitly for this sort of thing.

I tried platforms like Github Sponsors (Where I must continuously keep on 
searching for how to find the page every time) https://github.com/sponsors/ … 
however this didn’t work at all. I think I had one sponsor for 2 or 3 months, 
but that was a friend from the ASF. The problem is that the industry is used to 
buying products and not to consuming services. Also, a donation is not targeted 
and doesn’t work well with industrial book-keeping.

I tried contacting companies like tidelift, but no matter what I did, I never 
got any response, but instead every time I got more spam wanting to tell me 
about how awesome open-source is (Yeah … tell me about it ;-) )

I tried setting up a crowd-funding platform. The problem with the existing ones 
was, that they are not made for sponsoring feature development for open-source 
projects. I didn’t want to invest more time in preparing marketing videos for a 
campaign that takes longer to prepare than to implement the feature. As I 
couldn’t find any, I decided to setup my own. As I’m lazy and my website was 
based on WordPress I used WP-Crowdfunding 
(https://www.themeum.com/product/wp-crowdfunding-plugin/) … but I knew I had to 
have this legally checked. So, I hired a lawyer to check what I was planning on 
doing (Which is quite tricky … not many lawyers seemed to be willing to do 
that, guess most are just concentrating on the usual stuff).

Turns out (at least in Germany) a classical crowdfunding is not possible. The 
problem is that if a campaign is not successful, you must pay back the invested 
money. Above that you are required by law to pay interest on that. This is 
where things start getting interesting: As soon as you pay interest, you offer 
bank-like services. And this requires you to run your business through BAFIN. 
Which is a HUGE amount of paperwork and probably even expensive. The only 
option I had, was to run it as a donation without any repayments.

Of course, this again brings up the problem that donations don’t go down well 
in corporate accounting. So, I wasn’t expecting much to happen on my new 
crowdfunding platform. But I thought: If this should happen to work, I would 

RE: Re: Thoughts on alternative communication channels for our communities

[Christofer Dutz]

Hi Jarek,

I have thought of this before too as it has come up multiple times, mostly in 
my involvement as mentor for a new podling.
I do see one problem with "simply archive the emails automatically sent" ... 
most of them usually are in a form where it's not easily readable what actually 
happens. If there was a way to not only mirror what's happening in github 
issues or github discussions, but also some sort of injestion that makes the 
resulting stream of emails easily consumable by humans, I have no objections. 
But if in the end we just produce a new "email grave" for emails that are only 
usable as an excuse, I wouldn't want to see that.

Chris


-Original Message-
From: Jarek Potiuk  
Sent: Freitag, 18. Februar 2022 11:11
To: dev@community.apache.org
Subject: Re: Re: Thoughts on alternative communication channels for our 
communities

I think we can use many tools but when it comes to practicalities - I also 
think we should consider the important factor which is how easy it is to "join" 
and possibly "migrate".

For Airflow I think a huge benefit of GitHub discussions / Issues is that 
pretty much everyone is there already. No friction to join. if you do anything 
with Airflow - you already have an account there. Full Stop. Even If you want 
to raise an issue (our users are a huge part of the community)
- you need to have an account.
You already have some "notification" scheme set there (at the very least you 
get notified when you are mentioned). When you look at the numbers - our slack 
has 21.000 members. We have 25.000  stars on GitHub, 800 people watch what 
happens in the repo and we have more than 2000 contributors in GitHub.
If you try to move it elsewhere - good luck with achieving 10% conversion of 
that.

Also I perfectly understand it is different for different projects - and they 
are already often vested in their tools and the community is already gathering 
around some of those - I am by far the last to say "do as we do".
What works for us, might not work for others.

I personally believe we should simply embrace the diversity of tools for 
communication in ASF. Some projects can use Mattermost, Some free slack, Some 
Github. Some might focus more on the devlist and people will be comfortable 
there as well.

I think, rather than prescribing a specific solution, we should simply set the 
criteria (and those were nicely laid out by Mark) and let the projects choose.
Here where I see the INFRA role - is to work-out (with the help of others) some 
ways on how different communication media can full-fill the criteria.

For example in the case of Slack - we already have a tool (generic) that allows 
exporting and exposing ALL archives from a free slack
(automatically) - why not make the tool "blessed" by INFRA and made as a 
condition of using free slack by any project that wants it. Or a way to simply 
archive all the emails sent by GitHub Discussions and issues as a "archive 
owned by the ASF".
Then projects could simply choose what tools they want to use - if every tool 
would have a set of "checkboxes" to check and a way to verify automatically if 
they are followed that would be enough.

J.


On Fri, Feb 18, 2022 at 9:22 AM Hans Van Akelyen 
wrote:

> Hi All,
>
> My 2 cents on the matter, we have an application (Apache Hop) that is 
> mainly used by non developers so most of our questions are not of a 
> technical nature but more general hand-holding and troubleshooting. 
> Though it should be possible to do this via email you end up with a 
> tread of 20 mails back and forth "have you tried pressing x, and what 
> variables have you used,"
> These types of conversations are best handled synchronously so we were 
> looking at the ASF slack at first.
> Our feeling was that the threshold to enter the ASF slack was too 
> high. You either need an invite which is a single channel user or you 
> need to be a committer and we would be excluding Chinese users as 
> slack is blocked there.
>
> Therefore we set up our own Mattermost server which is an open source 
> slack alternative with no user limitations when managing your own 
> infrastructure.
>
> Though some development stuff is also discussed there we then point to 
> the developers list or add a summary there for further discussion.
>
> Cheers,
> Hans
>
> On Fri, 18 Feb 2022 at 01:58, Liu Ted  wrote:
>
> > We do need a modernized and/or complimentary communication channel. 
> > On many choices we have, I am also for GitHub Discussions for the 
> > benefits
> as
> > Matt Sicker described.
> > Another factor to consider is there is a Great Firewall (GFW) in 
> > China blocking many chat apps like Slack, Discord, Telegram, etc. 
> > unless using VPN whereas GitHub Discussions is accesible, no VPN 
> > needed, which allows and welcomes more easy communications with the 
> > foundation when adoption
> of
> > the Apache Way and its projects are booming in China.
> > Best regards,
> > Ted LiuASF member
> >
> >   2022 年 2 月 18 

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

[Christofer Dutz]

So, I generally agree with all of you:

1) I like the Idea of Badges
2) I dislike the way they could cause email/commit noise and discourage people 
from contributing.

I'll never forget my first visit to: 
http://people.apache.org/committer-index.html when I became a committer.
I'll never forget what I thought when seeing some of these other committers 
entries ... especially when they became (godlike) two-lined ones ;-)

But how about something like Badges for special situations a project runs into 
or for doing special tasks a project has?
- Being a Release Manager for a release
- Mentoring new Folks
- Saving the day for a problem a project is stuck on
- Helping a project in other ways (Councelling, Mediation, ...)
- I bet we also have ASF-Wide things we could say "thanks" with, by giving 
Badges (Conference work, Social Media Work, ...)

These could be badges the PMC or the respective groups vote on as form of 
recognition. And they could allow awarding folks doing important work, which 
doesn't directly map to numbers of commits/lines of code changed. I mean ... 
Assuming someone helps on a user list a lot with questions people have. Voting 
him in as a Committer and PPMC will probably not make him gain a significant 
merit based on commits, but if we had forms of recognition for this sort of 
thing, I think it would be a good motivation.

The Release-Manager badge might encourage more people to be motivated to learn 
how to do releases. I know several projects where the number of folks able to 
do a release is very limited.
Mentoring new Folks (even on TLPs) is hard work, would be a nice form of 
recognition.
Currently I see that people tend to vote in people coming from other projects 
for helping them with some tricky problems in a committer or PMC, if they help 
with big challenges a project is having. This might not be the ideal form of 
showing gratitude. A badge however might be exactly the right form.

Chris



-Ursprüngliche Nachricht-
Von: Mark Thomas  
Gesendet: Dienstag, 6. April 2021 09:50
An: dev@community.apache.org
Betreff: Re: New Apache.org product concept: Digital Merit Badges

On 06/04/2021 01:56, Justin Mclean wrote:



> Depending on the badges it might also easy to game. e.g. if I need 100 
> commits to get a badge, then I’m going to make lots of small commute rather 
> than one big one. If there a badge for emails send to lest then I’m going to 
> send more emails. I ‘m not sure that this would bee a positive gain for the 
> community.

+1 - I have similar concerns.

Now, if there was a way to take advantage of people's tendency to want more 
badges / a higher score to encourage behaviour that is a positive benefit to 
the community then that could be very interesting. I am thinking along the 
lines of Stackoverflow's reputation (although I recognise that that is not 
without issues). The biggest challenge is that it would need to work with 
mailing lists.

Maybe get a project, or a small number of projects, involved to run pilots of 
various schemes to see what works and what does not.

Mark

-
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

How about adding facemarks to our redbubble collection?

[Christofer Dutz]

Hi,

I was just looking if we had PLC4X face masks available on Redbubble and 
couldn’t find any …
How about adding these for our Apache projects in general? I’d definitely get 
at least one :-)

Chris

Re: Apache Training (incubating) granted all Apache committers commit rights

[Christofer Dutz]

Good point ;-)

I'll try to adjust that.

Chris


Am 05.10.20, 10:57 schrieb "Bertrand Delacretaz" :

Hi,

On Sun, Sep 27, 2020 at 12:59 PM Christofer Dutz
 wrote:
> ...We're opening up commit access to all Apache committers...

Great! It would be nice to mention this at http://training.apache.org/
, in the "Getting involved" section maybe?

-Bertrand

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

Apache Training (incubating) granted all Apache committers commit rights

[Christofer Dutz]

Hi,

We, the Apache Training PPMC, would like to tell you about an important
update by which you can promote & train people on your Apache project:
We're opening up commit access to all Apache committers.

We at Apache build all sorts of great software. Some people even create
training projects for Apache projects.
With the enormous pace of most of the projects, it's almost impossible to
keep training material up-to-date.
And even if you might know a given project, preparing training material
might be too much.
Also, even if you are a great coder, whipping up cool presentations might
not be your favourite thing to do.

Apache Training was created especially to help with all of this.

We created a framework for creating presentations in a coder friendly way
with features like versioning, tagging etc.
It is a RevealJS based presentation-framework using Asciidoctor; A
Markdown-like format but with a lot more control over the output and
additional features.
The primary supported build system is Maven. However, if you prefer, you
can also build your presentation with Ruby and Node.JS (The latter two are
still experimental).

The output is a Browser-based presentation with a dedicated speaker view,
which also allows exporting your presentation into PDF format for
distribution.

We would like to make Apache Training the place you look first if you are
in need of Apache related training or presentation material.

As you probably know your projects best, who would be better suited to help
with creating this material, if not you?

*Important Update*
That's why the Apache Training PPMC has turned on the commit permissions
for all Apache committers.

We trust that you will use these rights wisely. However, we do have one
restriction:
If you want to contribute to the fundamental presentation framework and the
tooling, please use PRs.
But when it comes to content, feel free to add and/or edit content for your
projects inside the 'content' directory as you see fit.
Please however exercise common sense about whether or not a PR is
appropriate, when changing content that other people created.

Note:
It seems that we can only grant all committers commit access on gitbox
and not on Github, so be sure to set our gitbox repo as "upstream" when
trying to commit:
https://gitbox.apache.org/repos/asf?p=incubator-training.git


*Please see this link for samples*
https://github.com/apache/incubator-training/tree/develop/content <
https://github.com/apache/incubator-training/tree/develop/content>


*Easy Steps to Create a Presentation*
To get you started in no-time, we provide Maven archetypes for generating
your presentation skeleton. In order to use this please just run:

mvn archetype:generate -DarchetypeGroupId=org.apache.training
-DarchetypeArtifactId=content-archetype -DarchetypeVersion=1.0.0

This will ask you for a group-id, artifact-id, version and a package-name
and as soon as you have provided them, will generate your new presentation.

To now build the presentation, change into the freshly created directory
and run:

mvn package

You can then run your presentation by opening the following file in your
browser:

target/generated-slides/index.html

We hope Apache Training will help you and your projects.

*The Apache Training (incubating) PPMC*

Re: Feathercast interview schedule

[Christofer Dutz]

Hi Rich,

Here goes ;-)

Apache PLC4X
Christofer Dutz
christofer.d...@c-ware.de
Central European Time

Chris


Von: Rich Bowen 
Gesendet: Freitag, 19. Juni 2020 17:20
An: ASF ComDev 
Betreff: Feathercast interview schedule

Hi again, folks,

I have allowed my backlog of recorded Feathercast interviews to run dry,
and I need to schedule some more. If you are interested in doing a
Feathercast for your project, please respond (preferably offlist) with

Project name
Your name
Your email address
Your time zone

and I'll add you to my spreadsheet. Thanks.

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

Re: Corona Track App

[Christofer Dutz]

Hi all,

I know the German government have created an App for the post-lockdown time 
that's DSVGO compliant.
Saw a news report on that a few days ago.

Seems to work by tracking Bluetooth devices around you. 

So if someone using the app gets tested positive, the system sends out alerts 
to anyone who was in contact with that person. 

Chris


Am 06.04.20, 08:21 schrieb "Raphael Bircher" :

Hi all

I made a Git repository https://github.com/rbircher/pandemie_track so
people who are interested can join

There is also a Gitter https://gitter.im/pandemie_track/community

I will soon add some Ideas to GitHub.

Regards Raphael

On Sun, Apr 5, 2020 at 6:31 PM Bertrand Delacretaz
 wrote:
>
> Hi Raphael,
>
> On Sun, Apr 5, 2020 at 3:06 PM Raphael Bircher  
wrote:
> > ...I know, Apache normally don't act proactive. But maybe we should make
> > an exception here. What do you think?...
>
> IMO it always boils down to finding people who actually have time to
> make things happen.
>
> If someone wants to start a software project related to the the
> current pandemic, starting in incubation is fairly easy,
> http://incubator.apache.org/cookbook/ has the details.
>
> There's also http://labs.apache.org/ although I don't think it's very
> active nowadays.
>
> I also noted recently https://www.pepp-pt.org/ and I understand it's
> meant to create an Open Source Privacy-Preserving Proximity Tracing
> protocol that might be quite useful in the next few months.
>
> Creating software around that might be cool, I'm not planning to help
> myself but the goal of Apache is to provide a space for cool projects
> ;-)
>
> -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: What license are the ICLA and CCLA available under?

[Christofer Dutz]

Hi all,

thanks for your responses. 

I created https://issues.apache.org/jira/browse/LEGAL-510 where this will 
hopefully be sorted out soon.

Really feel a little bad for opening so many legal issues recently.

Chris


Am 25.02.20, 16:55 schrieb "Shane Curcuru" :

Christofer Dutz wrote on 2020-2-25 6:32AM EST:
> Hi all,
> 
> I know this is a strange question, but what license are our ICLA and CCLA 
texts available under?
> I am asking because I’m involved in a new Open-Source project which is 
licensing it’s stuff under the Apache 2.0 license. The project is organized 
under a different freshly founded foundation. I suggested we put in place a 
system with ICLAs and CCLAs and thought the Apache ones would work nicely … 
unfortunately they don’t have License headers ;-)
> 
> Are our documents under Apache 2.0 License too?

The only place to get a definitive answer is from the Legal Affairs
Committee.

  https://www.apache.org/legal/#communications

You should open a JIRA asking both about these specific documents, and
about the case in general, so we can hopefully document this as a FAQ.

Elsethread, while I agree the Apache-2.0 license is a bit odd applied to
prose, my personal vote would be to treat everything the ASF publicly
produces as licensed under Apache-2.0 unless explicitly otherwise noted.
 The simplicity of saying "Everything from Apache not marked is
Apache-2.0" is a powerful statement (and much simpler to administer).

-- 

- 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

What license are the ICLA and CCLA available under?

[Christofer Dutz]

Hi all,

I know this is a strange question, but what license are our ICLA and CCLA texts 
available under?
I am asking because I’m involved in a new Open-Source project which is 
licensing it’s stuff under the Apache 2.0 license. The project is organized 
under a different freshly founded foundation. I suggested we put in place a 
system with ICLAs and CCLAs and thought the Apache ones would work nicely … 
unfortunately they don’t have License headers ;-)

Are our documents under Apache 2.0 License too?

Chris

[jira] [Commented] (COMDEV-356) Apache IoTDB integration with PLC4X and MiNiFI/NiFi

[Christofer Dutz (Jira)]

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

Christofer Dutz commented on COMDEV-356:


Hi Xiangdong Huang, 

I doubt comdev is the right project for this ... If I can help from the PLC4X 
side, please contact me on the PLC4X mailing list ... and I should mention we 
already have a PLC4X - NiFi integration and PLC4X - IoTDB examples.

Chris

> Apache IoTDB integration with PLC4X and MiNiFI/NiFi
> ---
>
> Key: COMDEV-356
> URL: https://issues.apache.org/jira/browse/COMDEV-356
> Project: Community Development
>  Issue Type: Wish
>  Components: GSoC/Mentoring ideas
>Reporter: Xiangdong Huang
>Priority: Major
>  Labels: IoTDB, gsoc2020
>
> IoTDB is a database for storing time series data.
> PLC4X is a driver to collect data from PLCs;
> MiNiFI is a data flow engine to transfer data from A to B, e.g., from PLC4X 
> to IoTDB.
> This proposal is for integration IoTDB with PLC4X and MiNiFi.
>  * When PLC4X collects data, it can send to IoTDB directly. 
>  * let MiNiFi/NiFi to support writing data into IoTDB.
>  
> Difficulty:  major
> mentors:
> h...@apache.org
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Re: Looking for community development stories

[Christofer Dutz]

Hi,

Perhaps the recording of my talk at the 2019 ApacheCon EU can help?

From an idea to an Apache TLP
https://www.youtube.com/watch?v=mD0Lh7si5Hc

There I'm talking about all of these phases and what I/we did in the PLC4X 
project.

Chris




Am 22.01.20, 05:48 schrieb "hannk...@163.com im Auftrag von Juan Pan" 
:

Hi Craig,


As the PPMC of Apache ShardingSphere (Incubating), i would like to share 
our experience of community growing. Hope it could provide some help to you. :-)


## The data of our community growing
As i summarized in our dev@list [1], we made a great improvement of 
community growing last year. More contributors, committers and PPMC joined us 
during 2019. Many thanks to Craig, Willem Jiang, Gosling, Justin and Sheng Wu.


## How to make community grow up


### Guideline
When we entered into incubator at the beginning, actually we did not have a 
better understanding of Apache way, and could not put community first. A 
guideline or docs are very important to tell us how to do to, or what we should 
do to walk on the road of Apache way. And [2] is a good manual, we thought.


### Performance
1. Be open and welcome anyone.
Since we are doing open-source, we should not put code beyond community and 
make the committer bar so high due to worrying about some wrong changes from 
community. 
After discussion in thread [3], we made our committer bar lower and began 
to be open to anyone.


2. Detailed Document
Document could help novice learn about your project quickly, and they could 
get some font help as well. We are continually add something new to documents, 
like [4], which will help committers do release easier
 and standard.


3. Volunteer issue list
A list of tasks or issues helping people who wants to learn or join to know 
what issues they can begin with. What’s more, issue list could also provide 
archived threads for users.


4. Talking open
We would like to make our main talkings open to let anyone know what is 
happening in our community, which gives people sense of participation. 
Meanwhile, some important discussion or conclusion will be pushed into 
our dev mail list.


5. Promotion
Sometimes, we are invited to give some talkings in conferences or hold our 
meet-up [5]. It is very important to let people know you, and maybe become 
interested in you. I guess this is the first step to interact with your 
community.


6. Listen to mentor or other communities’ advices
Just as this title said, we are willing to listen to your valuable opinions 
or experiences. Would you like to share your idea to us? Thanks in advance.






Oh, it is a long article. I guess only a few of people would give it a 
look… But, i am willing to share those things, and appreciated if you could get 
something from it.


Best wishes to everyone.


Trista




[1] 
https://lists.apache.org/thread.html/r344a38974cd737678e23f8f94338a4a022e6b90bc75ea67fef226dde%40%3Cdev.shardingsphere.apache.org%3E
[2] 
https://community.apache.org/apache-way/apache-project-maturity-model.html
[3] 
https://lists.apache.org/thread.html/e8d5ab2ea936fcb1205f7a0ee80aedfae90649c80f96dffa458ef341%40%3Cdev.shardingsphere.apache.org%3E
[4] https://shardingsphere.apache.org/community/en/contribute/release/
[5] https://twitter.com/ShardingSphere


 Juan Pan (Trista) 
 
Senior DBA & PPMC of Apache ShardingSphere(Incubating)
E-mail: panj...@apache.org




On 01/22/2020 09:30，Craig Russell wrote：
Hi,

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

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

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

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

Thanks,

Craig

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: 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: 

Re: Conference software

[Christofer Dutz]

Hi all,

yeah ... didn't quite see what you were asking for ... for the ApacheCon NA 
this and last year we used the open-source project DukeCon. 
I'm part of the development team ... for this year I would love a little more 
heads-up in order to fully integrate it with our CFP system.
I think Rich would love that ... unless he developed a slightly sadistic 
tendency to love editing JSON files ;-)

So if you're looking for that ... just talk to me about it.

Chris



Am 02.01.20, 14:28 schrieb "Rich Bowen" :



On 12/27/19 6:16 AM, Kevin A. McGrail wrote:
> Yes, we just bought it for another year.  Cc'ing Rich Bowen to share info.

No, that is not correct. I presume you're thinking of the CFP (Call For 
Presentations) tool that we use?

ApacheCon Europe used something different from what we used for 
ApacheCon North America - DukeCon - which you can see at 
https://www.apachecon.com/acna19/s

DukeCon is open source, and we were helped by the team that develops it, 
and, specifically, Chris Dutz.

The ACEU schedule is something else. I know I knew what it was called at 
some point, but I cannot find that information right now. I'm sure that 
Paul Berschick knows.

> 
> On Fri, Dec 27, 2019, 04:25 Driesprong, Fokko  
wrote:
> 
>> Hi all,
>>
>> At the Apache Airflow project, we're looking at organizing two summits, 
one
>> in the US, and one in the EU. I've noticed that we're having some kind of
>> software for managing the sessions and the speakers:
>> https://aceu19.apachecon.com/schedule?day=2019-10-22
>>
>> My question is, does anyone know which software this is? And if this can 
be
>> used for any Apache related conferences like Airflow?
>>
>> Please let me know,
>>
>> Kind regards,
>> Fokko Driesprong
>>
> 

-
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: Membership in Industry Organizations?

[Christofer Dutz]

Hi Kevin,

sure ... actually informing the Board was the first thing I did as I thought 
that's where it belonged and I was asked to bring it here.
But happy to open legal tickets for each agreement. That was the information I 
was looking for ;-)

Chris


Am 03.12.19, 14:38 schrieb "Mark Thomas" :

On 03/12/2019 13:25, Christofer Dutz wrote:
> Ok ... 
> 
> So If I don't hear any objections in 72 hours, I'll treat that as 
consensus and I'll start creating these memberships for the PLC4X project but 
on behalf of the ASF.

If the are agreements to agree to, I'd *strongly* recommend you get them
reviewed by the legal committee before signing them.

I'd give board@ a heads-up and time to comment first.

Mark

> 
> Chris
> 
> 
    > Am 02.12.19, 22:44 schrieb "Christofer Dutz" :
> 
> Hi all,
> 
> I think I brought this up before, but it’s getting more important now.
> Till now it was just Apache PLC4X which would profit from this, but 
now that we also have Apache StreamPipes, there’s a second project that would 
benefit.
> 
> In order to implement some industry protocols, you need to be member 
of the organization behind the protocol.
> 
> The ones I am talking about are:
> 
>   *   OPC Foundation (Logo-Membership to be allowed to use the OPC-UA 
logo and name as well as access the specs) … costs 0$/Year
>   *   EtherCat organization (Logo-Membership to be allowed to use the 
EzherCAT Logo, access the specs and request a Vendor ID) … costs 0$/year
>   *   ProfiNet organization (Free Membership to be allowed to use the 
ProfiNet Logo and request a vendor ID) … costs 0$/year
> 
> The EtherCat and ProfiNet protocols would require a Vendor id, which 
would identify any driver implementations as Apache software.
> The PLC4X Project requires these both in order to be able to 
implement active drivers.
> The PLC4X and StreamPipes projects both require the 3 
logo-memberships in order to be allowed to use the Logo and Names of the 
protocols.
> 
> Are there any objection for me to go ahead and start the paperwork 
(or just filling out the online forms)?
> Being the VP of PLC4X I should be able to do this (Being an officer 
of the Foundation)
> 
> 
> 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: Membership in Industry Organizations?

[Christofer Dutz]

Ok ... 

So If I don't hear any objections in 72 hours, I'll treat that as consensus and 
I'll start creating these memberships for the PLC4X project but on behalf of 
the ASF.

Chris


Am 02.12.19, 22:44 schrieb "Christofer Dutz" :

Hi all,

I think I brought this up before, but it’s getting more important now.
Till now it was just Apache PLC4X which would profit from this, but now 
that we also have Apache StreamPipes, there’s a second project that would 
benefit.

In order to implement some industry protocols, you need to be member of the 
organization behind the protocol.

The ones I am talking about are:

  *   OPC Foundation (Logo-Membership to be allowed to use the OPC-UA logo 
and name as well as access the specs) … costs 0$/Year
  *   EtherCat organization (Logo-Membership to be allowed to use the 
EzherCAT Logo, access the specs and request a Vendor ID) … costs 0$/year
  *   ProfiNet organization (Free Membership to be allowed to use the 
ProfiNet Logo and request a vendor ID) … costs 0$/year

The EtherCat and ProfiNet protocols would require a Vendor id, which would 
identify any driver implementations as Apache software.
The PLC4X Project requires these both in order to be able to implement 
active drivers.
The PLC4X and StreamPipes projects both require the 3 logo-memberships in 
order to be allowed to use the Logo and Names of the protocols.

Are there any objection for me to go ahead and start the paperwork (or just 
filling out the online forms)?
Being the VP of PLC4X I should be able to do this (Being an officer of the 
Foundation)


Chris



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

Membership in Industry Organizations?

[Christofer Dutz]

Hi all,

I think I brought this up before, but it’s getting more important now.
Till now it was just Apache PLC4X which would profit from this, but now that we 
also have Apache StreamPipes, there’s a second project that would benefit.

In order to implement some industry protocols, you need to be member of the 
organization behind the protocol.

The ones I am talking about are:

  *   OPC Foundation (Logo-Membership to be allowed to use the OPC-UA logo and 
name as well as access the specs) … costs 0$/Year
  *   EtherCat organization (Logo-Membership to be allowed to use the EzherCAT 
Logo, access the specs and request a Vendor ID) … costs 0$/year
  *   ProfiNet organization (Free Membership to be allowed to use the ProfiNet 
Logo and request a vendor ID) … costs 0$/year

The EtherCat and ProfiNet protocols would require a Vendor id, which would 
identify any driver implementations as Apache software.
The PLC4X Project requires these both in order to be able to implement active 
drivers.
The PLC4X and StreamPipes projects both require the 3 logo-memberships in order 
to be allowed to use the Logo and Names of the protocols.

Are there any objection for me to go ahead and start the paperwork (or just 
filling out the online forms)?
Being the VP of PLC4X I should be able to do this (Being an officer of the 
Foundation)


Chris

Re: projects.apache.org urls showing in some projects categories

[Christofer Dutz]

Hi,

Well as far as I understood it, this data is provided by the RDF files projects 
maintain themselves.
I too noticed some time ago the "iot" category was only used by Apache Camel, 
so I fixed this at least for Apache PLC4X.
We integrated this into our code-repo and the site-generation:
https://github.com/apache/plc4x/blob/develop/src/site/resources-filtered/plc4x-doap.rdf

And I just noticed it is slightly out of date with respect to our latest 
releases.

Chris


Am 25.10.19, 01:26 schrieb "sebb" :

On Thu, 24 Oct 2019 at 23:30, Nick Burch  wrote:
>
> Hi All
>
> I've spotted what looks like a data bug, but might be a code bug, on
> projects.apache.org. For some projects, they are being shown not against
> their proper category (eg library), but against a category that's prefixed
> with the https://projects.a.o link for their category
>
> For example, Apache Tika is showing as a category of
> https://projects.apache.org/projects.html?category#library instead of just
> library. You can see that at
> 
https://projects.apache.org/projects.html?category#https://projects.apache.org/projects.html?category#library

That is a data bug.

See https://projects.apache.org/guidelines.html for category syntax.

> Thanks
> Nick
>
> -
> 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: Workshop about the future of Open Source Software and Open Source Hardware

[Christofer Dutz]

Hi Roman,

Well simply go to the website I posted a link for and sign up ... 
however I have signed up and got a "we'll check your application" and haven't 
heard from them since then.
But I would assume from the registration process that this is open to citizens 
of the European Union ... but you could try.

Chris

Am 15.10.19, 03:30 schrieb "Roman Shaposhnik" :

A bit of a belated reply -- but this looks very interesting to me on
both open source and business sized (my company -- ZEDEDA is right in
the middle of all this change).

So... a question: how can I sign up for this event?

Thanks,
Roman.

On Mon, Oct 7, 2019 at 2:26 AM Christofer Dutz
 wrote:
>
> Hi all,
>
> They already changed the wording slightly ... now they write that Siemens 
MindSphere USES a lot of Open-Source software.
> Still not happy with it being mentioned directly after the: "There are a 
lot of Open-Source platforms", but it sort of feels as if Siemens had pulled 
some strings to be mentioned here (The official Agenda doesn't even mention 
"Siemens" or "MindSphere")
>
> I just discussed this with my boss and I'll probably be going.
> Would however be great to show up there with a little (or a big) Apache 
delegation.
> The big commercial players could be showing up with quite a delegation.
> After all it's not about Apache PLC4X, but could involve a great portion 
of what Apache does.
> And especially the Panel discussions about:
>
> "Panel 2.2: Nurturing Open Source Communities
> In the backdrop of the increasing popularity and use of open source
> software, it is a paradox that many open source projects continue to
> struggle to sustain themselves. Remarkably, sustainability issues
> afflict not just the small and medium-sized project, but also some of
> the larger and well-known ones.
> The success of open source software initiatives often goes hand in
> hand with the success of their communities. So what are the success
> factors leading to a sustainable community? What are the key
> challenges open source projects face? More importantly, what can
> and should be done about the sustainability and funding issue?
> This session invites a brief discussion to identify key sustainability
> concerns, followed by two deeper debates on practical
> proposals/solutions to solve (i) Sustainability issues (ii) Funding
> issues. The session combines results and inputs from the
> Commission’s EU-FOSSA project and the Commission’s Open
> Source Observatory (OSOR)"
>
> "Panel 7: Improving openness, trust and security thanks to open
> source
> The advent of emerging technologies like Artificial Intelligence and
> block chain and the exponential increase on cybersecurity threats
> made the demand for security, trust and transparency in decision
> making as key priorities in designing ICT systems. Open source is seen
> as a mechanism to ensure such characteristics. The purpose of this
> session is to highlight the role of Open Source towards achieving
> security, trust and transparency in decision-making. What are the
> strengths but also what are the weaknesses and limitations? The
> session combines results and inputs from the Commission’s EUFOSSA 
project."
>
> Chris
>
> Am 07.10.19, 10:38 schrieb "Julian Feinauer" 
:
>
> Hi all,
>
> sorry for being late to the party.
> I totally agree with all that has been written.
> And although I will not be able to participate I think we should work 
on having them correct that (on paper and in their minds).
> Probably we could even do that as an official statement of the ASF or 
use some contacts to other OSS initiatives.
> As I see that as a rather general matter to hijack "OSS".
>
> What do you think?
>
> Julian
>
> Am 06.10.19, 11:48 schrieb "Christofer Dutz" 
:
>
> Hi Michael,
>
> Yes, that too was my impression. I remember the amount of work 
you put in here. But it seems that Siemens likes to appear open without 
actually being open for open source. That's why I contacted the organizers and 
tried to convince them to correct this paragraph and suffered that they invite 
tuely open open-source communities.
>
> I'll be discussing with my boss, if I can attend.
    >
    > Chris
>
> Holen Sie sich Outlook für Android<https://aka.ms/ghei36>
>
> 
>

Re: Workshop about the future of Open Source Software and Open Source Hardware

[Christofer Dutz]

My email helped, they fixed that paragraph.

But instead of complaining via email. I think it's a better approach to 
actually attend that two day workshop and to show them how open source works. I 
mean which organization is better suited to talk about this than the ASF.

So I got a green light from my company to go. Would be great if others could 
join.

Being on the comdev PMC... Are there any objections of me not only wearing my 
iot, but also my apache comdev hat?

Anyone interested in joining in?

Chris

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Julian Feinauer 
Sent: Monday, October 7, 2019 10:28:42 AM
To: dev@community.apache.org 
Subject: Re: Workshop about the future of Open Source Software and Open Source 
Hardware

Hi all,

sorry for being late to the party.
I totally agree with all that has been written.
And although I will not be able to participate I think we should work on having 
them correct that (on paper and in their minds).
Probably we could even do that as an official statement of the ASF or use some 
contacts to other OSS initiatives.
As I see that as a rather general matter to hijack "OSS".

What do you think?

Julian

Am 06.10.19, 11:48 schrieb "Christofer Dutz" :

Hi Michael,

Yes, that too was my impression. I remember the amount of work you put in 
here. But it seems that Siemens likes to appear open without actually being 
open for open source. That's why I contacted the organizers and tried to 
convince them to correct this paragraph and suffered that they invite tuely 
open open-source communities.

I'll be discussing with my boss, if I can attend.

Chris

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Michael Osipov 
Sent: Saturday, October 5, 2019 6:31:01 PM
    To: dev@community.apache.org ; Christofer Dutz 
; i...@apache.org 
Subject: Re: Workshop about the future of Open Source Software and Open 
Source Hardware

    Am 2019-10-05 um 17:20 schrieb Christofer Dutz:
> Hi,
>
> Lukasz just posted this on the plc4x slack channel mainly because of 
Siemens’ attempt to appear open:
> “There are also B2B Open Source platforms: Siemens’ MindSphere offers a 
managed open source Platform-as-a-Service for developing cross-platform 
applications” (Which it clearly is not).
>
> But when I read through the Agenda I think it might be a good idea to 
show up with a little Apache delegation:
> 
https://ec.europa.eu/digital-single-market/en/news/workshop-about-future-open-source-software-and-open-source-hardware
>
> Seems to be not a Workshop where you are fuled up with some stuff, but 
where people come together to form the appearance of Open-Source in the 
Industry.

This cannot be right/true. I have tried for more than a year to engage
with DI (digital infrastructure) and utterly failed. My fellow coworker
in Nuremberg told me that we (DI) don't want to engage with the OSS
community at any kind of level. After that, I left the topic w/o any
prosperity for the company and the OSS community.

Michael




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

Re: Workshop about the future of Open Source Software and Open Source Hardware

[Christofer Dutz]

Hi all,

They already changed the wording slightly ... now they write that Siemens 
MindSphere USES a lot of Open-Source software. 
Still not happy with it being mentioned directly after the: "There are a lot of 
Open-Source platforms", but it sort of feels as if Siemens had pulled some 
strings to be mentioned here (The official Agenda doesn't even mention 
"Siemens" or "MindSphere")

I just discussed this with my boss and I'll probably be going. 
Would however be great to show up there with a little (or a big) Apache 
delegation. 
The big commercial players could be showing up with quite a delegation.
After all it's not about Apache PLC4X, but could involve a great portion of 
what Apache does. 
And especially the Panel discussions about: 

"Panel 2.2: Nurturing Open Source Communities
In the backdrop of the increasing popularity and use of open source
software, it is a paradox that many open source projects continue to
struggle to sustain themselves. Remarkably, sustainability issues
afflict not just the small and medium-sized project, but also some of
the larger and well-known ones.
The success of open source software initiatives often goes hand in
hand with the success of their communities. So what are the success
factors leading to a sustainable community? What are the key
challenges open source projects face? More importantly, what can
and should be done about the sustainability and funding issue?
This session invites a brief discussion to identify key sustainability
concerns, followed by two deeper debates on practical
proposals/solutions to solve (i) Sustainability issues (ii) Funding
issues. The session combines results and inputs from the
Commission’s EU-FOSSA project and the Commission’s Open
Source Observatory (OSOR)"

"Panel 7: Improving openness, trust and security thanks to open
source
The advent of emerging technologies like Artificial Intelligence and
block chain and the exponential increase on cybersecurity threats
made the demand for security, trust and transparency in decision
making as key priorities in designing ICT systems. Open source is seen
as a mechanism to ensure such characteristics. The purpose of this
session is to highlight the role of Open Source towards achieving
security, trust and transparency in decision-making. What are the
strengths but also what are the weaknesses and limitations? The
session combines results and inputs from the Commission’s EUFOSSA project."

Chris

Am 07.10.19, 10:38 schrieb "Julian Feinauer" :

Hi all,

sorry for being late to the party.
I totally agree with all that has been written.
And although I will not be able to participate I think we should work on 
having them correct that (on paper and in their minds).
Probably we could even do that as an official statement of the ASF or use 
some contacts to other OSS initiatives.
As I see that as a rather general matter to hijack "OSS".

What do you think?

Julian

Am 06.10.19, 11:48 schrieb "Christofer Dutz" :

Hi Michael,

Yes, that too was my impression. I remember the amount of work you put 
in here. But it seems that Siemens likes to appear open without actually being 
open for open source. That's why I contacted the organizers and tried to 
convince them to correct this paragraph and suffered that they invite tuely 
open open-source communities.

I'll be discussing with my boss, if I can attend.

Chris

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Michael Osipov 
Sent: Saturday, October 5, 2019 6:31:01 PM
To: dev@community.apache.org ; Christofer 
Dutz ; i...@apache.org 
Subject: Re: Workshop about the future of Open Source Software and Open 
Source Hardware

Am 2019-10-05 um 17:20 schrieb Christofer Dutz:
> Hi,
>
> Lukasz just posted this on the plc4x slack channel mainly because of 
Siemens’ attempt to appear open:
> “There are also B2B Open Source platforms: Siemens’ MindSphere offers 
a managed open source Platform-as-a-Service for developing cross-platform 
applications” (Which it clearly is not).
>
> But when I read through the Agenda I think it might be a good idea to 
show up with a little Apache delegation:
> 
https://ec.europa.eu/digital-single-market/en/news/workshop-about-future-open-source-software-and-open-source-hardware
>
> Seems to be not a Workshop where you are fuled up with some stuff, 
but where people come together to form the appearance of Open-Source in the 
Industry.

This cannot be right/true. I have tried for more than a year to engage
with DI (digital infrastructure) and utterly failed. My fellow coworker

Re: Workshop about the future of Open Source Software and Open Source Hardware

[Christofer Dutz]

Hi Michael,

Yes, that too was my impression. I remember the amount of work you put in here. 
But it seems that Siemens likes to appear open without actually being open for 
open source. That's why I contacted the organizers and tried to convince them 
to correct this paragraph and suffered that they invite tuely open open-source 
communities.

I'll be discussing with my boss, if I can attend.

Chris

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Michael Osipov 
Sent: Saturday, October 5, 2019 6:31:01 PM
To: dev@community.apache.org ; Christofer Dutz 
; i...@apache.org 
Subject: Re: Workshop about the future of Open Source Software and Open Source 
Hardware

Am 2019-10-05 um 17:20 schrieb Christofer Dutz:
> Hi,
>
> Lukasz just posted this on the plc4x slack channel mainly because of Siemens’ 
> attempt to appear open:
> “There are also B2B Open Source platforms: Siemens’ MindSphere offers a 
> managed open source Platform-as-a-Service for developing cross-platform 
> applications” (Which it clearly is not).
>
> But when I read through the Agenda I think it might be a good idea to show up 
> with a little Apache delegation:
> https://ec.europa.eu/digital-single-market/en/news/workshop-about-future-open-source-software-and-open-source-hardware
>
> Seems to be not a Workshop where you are fuled up with some stuff, but where 
> people come together to form the appearance of Open-Source in the Industry.

This cannot be right/true. I have tried for more than a year to engage
with DI (digital infrastructure) and utterly failed. My fellow coworker
in Nuremberg told me that we (DI) don't want to engage with the OSS
community at any kind of level. After that, I left the topic w/o any
prosperity for the company and the OSS community.

Michael

Workshop about the future of Open Source Software and Open Source Hardware

[Christofer Dutz]

Hi,

Lukasz just posted this on the plc4x slack channel mainly because of Siemens’ 
attempt to appear open:
“There are also B2B Open Source platforms: Siemens’ MindSphere offers a managed 
open source Platform-as-a-Service for developing cross-platform applications” 
(Which it clearly is not).

But when I read through the Agenda I think it might be a good idea to show up 
with a little Apache delegation:
https://ec.europa.eu/digital-single-market/en/news/workshop-about-future-open-source-software-and-open-source-hardware

Seems to be not a Workshop where you are fuled up with some stuff, but where 
people come together to form the appearance of Open-Source in the Industry.

Just thought I’d share,
Chris

Re: Some available Hotel Rooms for ApacheCon EU 2019 in Berlin

[Christofer Dutz]

There is still one room available...

Chris

Holen Sie sich Outlook für Android<https://aka.ms/ghei36>


From: Myrle Krantz 
Sent: Tuesday, September 24, 2019 7:47:50 PM
To: dev@community.apache.org 
Subject: Re: Some available Hotel Rooms for ApacheCon EU 2019 in Berlin

Hi Aizhamal,

In case Chris doesn't have any thing for you, NewThinking has put some
effort into finding hotels close to the conference.  You can check out the
guide here:
https://aceu19.apachecon.com/accommodation

Best,
Myrle

On Mon, Sep 23, 2019 at 11:24 PM Aizhamal Nurmamat kyzy
 wrote:

> Hi Chris,
>
> Is there a chance I still can get one of the available rooms? I arrive on
> the 21st and leave on the 25th.
>
> On Fri, Aug 30, 2019 at 7:04 AM Christofer Dutz  >
> wrote:
>
> > Hi all,
> >
> > we have 4 rooms which we blocked for TAC and won’t be needing.
> >
> > Here the details:
> >
> > Hotel Kastanienhof Berlin
> > https://www.kastanienhof.berlin/
> >
> > Arrival: 20.10.2019 (check in available at 2 pm)
> > Departure: 25.10.2019 (check out until 11 am)
> > Roomtype: 1 Standard double room
> > Price: 89,00 € per room and night
> > Roomtype: 2 Comfort double rooms
> > Price: 99,00 € per room and night
> > Roomtype: 1 Deluxe double room
> > Price: 119,00 € per room and night
> >
> > If anyone of you is still in need of a Hotel room closely located to the
> > ApacheCon venue, please contact me directly.
> >
> > Also might we be able to adjust the arrival and departure days a little,
> > but I have to call them first.
> >
> > Chris
> >
>

Re: Shared service for Websites?

[Christofer Dutz]

Hi Sebb,

Ok ... sent an email ... this was also what I was actually asking for ... so 
thanks ;-)

Chris

Am 18.09.19, 23:37 schrieb "sebb" :

On Wed, 18 Sep 2019 at 21:35, Christofer Dutz  
wrote:
>
> Hi all,
>
> well we technically have a site up and running nicely. It's content is 
part of the project itself. It's automatically built and deployed by Jenkins.
> We use asciidoctor and the maven-site-plugin to generate the content for 
it.
> The problem is that is just doesn't look so great.
> http://plc4x.apache.org/
>
> So it's more the art part of web-design and/or the art of texting we 
could need some help with ;-)

That sounds like a job for Central Services.
Try contacting them on centralservi...@apache.org

> We've got the technical base well covered.
>
> Chris
>
> Am 18.09.19, 21:33 schrieb "Roy Lenferink" :
>
> Recently Celix migrated from the Apache CMS to hosting the website 
through
> the gitpubsub system as well.
> For Celix we're using Hugo meaning our content is written in markdown.
>
> If you want to have a look please do here: http://celix.apache.org/
> The source exists here: https://github.com/apache/celix-site
>
> Roy
>
> Op wo 18 sep. 2019 om 16:33 schreef Owen O'Malley 
:
>
> > Since all of the Apache projects have their websites checked in, 
find one
> > you like and copy the style and start from there. That is how 
Calcite
> > <https://calcite.apache.org/>'s page ended up looking at lot like 
ORC
> > <https://orc.apache.org/>'s.
> > ..Owen
> >
> >
> > On Wed, Sep 18, 2019 at 6:16 AM Christofer Dutz 
 > >
> > wrote:
> >
> > > Hi all,
> > >
> > > I just wanted to ask if there is any “shared service” or nice 
person that
> > > could help the PLC4X Website.
> > > It’s sort of looked the same since I initiated the project and I 
think
> > > it’s not quite in a state that will make people get interested in 
what
> > > we’re doing.
> > > As I really suck greatly at web-design, I just wanted to ask if 
there is
> > > any shared service or someone willing to help us with improving 
it.
> > >
> > > Would be happy for some positive feedback,
> > > 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: Shared service for Websites?

[Christofer Dutz]

Hi all,

well we technically have a site up and running nicely. It's content is part of 
the project itself. It's automatically built and deployed by Jenkins. 
We use asciidoctor and the maven-site-plugin to generate the content for it. 
The problem is that is just doesn't look so great. 
http://plc4x.apache.org/

So it's more the art part of web-design and/or the art of texting we could need 
some help with ;-)
We've got the technical base well covered.

Chris

Am 18.09.19, 21:33 schrieb "Roy Lenferink" :

Recently Celix migrated from the Apache CMS to hosting the website through
the gitpubsub system as well.
For Celix we're using Hugo meaning our content is written in markdown.

If you want to have a look please do here: http://celix.apache.org/
The source exists here: https://github.com/apache/celix-site

Roy

Op wo 18 sep. 2019 om 16:33 schreef Owen O'Malley :

> Since all of the Apache projects have their websites checked in, find one
> you like and copy the style and start from there. That is how Calcite
> <https://calcite.apache.org/>'s page ended up looking at lot like ORC
> <https://orc.apache.org/>'s.
> ..Owen
>
>
> On Wed, Sep 18, 2019 at 6:16 AM Christofer Dutz  >
> wrote:
>
> > Hi all,
> >
> > I just wanted to ask if there is any “shared service” or nice person 
that
> > could help the PLC4X Website.
> > It’s sort of looked the same since I initiated the project and I think
> > it’s not quite in a state that will make people get interested in what
> > we’re doing.
> > As I really suck greatly at web-design, I just wanted to ask if there is
> > any shared service or someone willing to help us with improving it.
> >
> > Would be happy for some positive feedback,
> > Chris
> >
>

Shared service for Websites?

[Christofer Dutz]

Hi all,

I just wanted to ask if there is any “shared service” or nice person that could 
help the PLC4X Website.
It’s sort of looked the same since I initiated the project and I think it’s not 
quite in a state that will make people get interested in what we’re doing.
As I really suck greatly at web-design, I just wanted to ask if there is any 
shared service or someone willing to help us with improving it.

Would be happy for some positive feedback,
Chris

Some available Hotel Rooms for ApacheCon EU 2019 in Berlin

[Christofer Dutz]

Hi all,

we have 4 rooms which we blocked for TAC and won’t be needing.

Here the details:

Hotel Kastanienhof Berlin
https://www.kastanienhof.berlin/

Arrival: 20.10.2019 (check in available at 2 pm)
Departure: 25.10.2019 (check out until 11 am)
Roomtype: 1 Standard double room
Price: 89,00 € per room and night
Roomtype: 2 Comfort double rooms
Price: 99,00 € per room and night
Roomtype: 1 Deluxe double room
Price: 119,00 € per room and night

If anyone of you is still in need of a Hotel room closely located to the 
ApacheCon venue, please contact me directly.

Also might we be able to adjust the arrival and departure days a little, but I 
have to call them first.

Chris

Re: REMINDER: Project Stickers for Apachecon NA or EU

[Christofer Dutz]

I know the plc4x project is on the list... Just wanted to make sure we're in 
one of the batches.

Chris

Holen Sie sich Outlook für Android


From: Sharan Foga 
Sent: Tuesday, August 13, 2019 8:13:26 PM
To: dev@community.apache.org 
Subject: Re: REMINDER: Project Stickers for Apachecon NA or EU

Hi Owen

Yes sure. Will add ORC.

Thanks
Sharan

On 2019/08/13 18:01:26, "Owen O'Malley"  wrote:
> Can we add ORC stickers?
>
> Thanks,
>Owen
>
> On Tue, Aug 13, 2019 at 10:51 AM Sharan Foga  wrote:
>
> > Hi Dmitriy
> >
> > No problem and responding here is fine. I will add Ignite.
> >
> > And I've already included some stickers for Apache Training in my first
> > order :-)
> >
> > Thanks
> > Sharan
> >
> > On 2019/08/13 17:42:17, Dmitriy Pavlov  wrote:
> > > Hi Sharan,
> > >
> > > Can I ask you to include Apache Ignite stickers to the order?
> > > http://apache.org/logos/#ignite
> > > Talks related to Apache Ignite will be both at Apache Con NA (Denis
> > Magda)
> > > and Apache Con EU (Alexey Zinoviev).
> > >
> > > Also, I participate in Apache Training (incubating)
> > > http://apache.org/logos/?#training
> > > This polding related talks will be held at least at Apache Con EU. So
> > could
> > > you please add it, as well?
> > >
> > > Should I start 2 separate threads at Com.Dev list? Or is it enough to
> > reply
> > > in this email?
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > вт, 13 авг. 2019 г. в 20:12, Sharan Foga :
> > >
> > > > Hi All
> > > >
> > > > We still have a little time to put together a second order for stickers
> > > > for the ASF booth for Las Vegas and Berlin. I already have a couple of
> > > > projects on the second order so if you would like us to have some of
> > your
> > > > project stickers too then please let me know and I will include it.
> > > >
> > > > This includes incubating projects too so if you have never seen or had
> > any
> > > > stickers available for your project then this is the time to request
> > some!
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > > On 2019/08/07 19:51:25, Sharan Foga  wrote:
> > > > > Hi Everyone
> > > > >
> > > > > This is a reminder that I am putting the main sticker order together
> > now
> > > > with the plan to get the order in progress by the weekend. So if you
> > are
> > > > coming to Apachecon NA or EU and would like to see some of your project
> > > > stickers there then please let me know. And remember this covers
> > podlings
> > > > too.
> > > > >
> > > > > Please check to see if your project is already on the Sticker list at
> > > > > https://cwiki.apache.org/confluence/display/COMDEV/ApacheCon+NA+2019
> > > > >
> > > > > and if not, then please either add it to the list on the wiki or
> > respond
> > > > to this thread with the name of your project and I will add it.
> > > > >
> > > > > 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

How to add swag to the redbubble shop?

[Christofer Dutz]

Hi all,

I'm currently reading all of these "please add project x logo to redbubble". 
The plc4x project would also like to do this, but I expect more than just 
adding a logo being necessary for that.

I would volunteer to do that for the plc4x project.

Chris


Holen Sie sich Outlook für Android

Re: New inter-project Mailinglist i...@apache.org created

[Christofer Dutz]

Hi Bertrand,

think probably blogs.apache.org would be the better way. Even if I'm mainly 
involved in this
I am not PLC4X and don't want to create the impression it's a PLC4X party (Even 
if PLC4X parties rock ;-) )

For that I'll probably better talk to sally, correct or who's in charge of the 
blog?

But in the end we'll still be sending out emails so perhaps a little 
duplication doesn't harm.

Chris


Am 05.07.19, 15:34 schrieb "Bertrand Delacretaz" :

Hi,

On Fri, Jul 5, 2019 at 3:06 PM Christofer Dutz
 wrote:
> ...I'll whip up an email text and we'll fire it out...

IMHO a persistent URL is more effective as it allows you to
re-advertise later as needed.

Maybe something at http://plc4x.apache.org/ as you are driving this,
or under https://blogs.apache.org/comdev/

And you can then send that URL by email + twitter or any other channel etc.

-Bertrand

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

[Draft] Announcing new inter-project mailing list for Apache IoT related projects

[Christofer Dutz]

Hi all,

in order to improve the communication and exchange between Apache IoT projects, 
we have decided to create a mailing list for IoT related topics and projects.

We have noticed that several projects have been addressing the same tasks 
multiple times, just because they didn’t know about other projects working on 
the same things.

This list is planned to be a useful tool to reach out to other projects and 
communities in the same sector.
Use it to ask for help, tell others about some great new features that might 
help other projects, discuss general ideas.
We hope it will help us build our projects in a way that they fit together 
better, extend each other and in general help each other.

So if you are involved in any IoT related projects (not just at Apache), wish 
to participate or just want to know what’s going on, just subscribe:

i...@apache.org

by sending an Email to:

iot-subscr...@apache.org

Looking forward to some great discussions :-)

Chris
(on behalf of the Apache Community Development Team)

Re: New inter-project Mailinglist i...@apache.org created

[Christofer Dutz]

Hi all,

well I guess, I'll whip up an email text and we'll fire it out to announce and 
committers as a first shot and then post to lists I think would be a good match 
in addition to that.
I agree, it is some work, but I always knew it would be. And I still think it's 
worth it.

Chris

Am 05.07.19, 14:50 schrieb "Rich Bowen" :



On 7/5/19 3:06 AM, Christofer Dutz wrote:
> Hi all,
> 
> our new i...@apache.org<mailto:i...@apache.org> mailing list has been 
created and is now waiting for subscribers :-)
> 
> What do you think would be the best way to advertise this?
> 
>1.  Send an email to each pmc in the IoT sector

I would think that announcing this to the dev/user lists would get you a 
broader audience of people interested in what you're doing.

As Bertrand notes, if you build it, they won't come. You'll have to go 
find them. And it's totally worth the effort. Cross-project discussions 
are almost always beneficial to everyone, particularly when you're all 
solving similar problems different ways.

>2.  Send an Announce email over the usual announce@ list
>3.  Send to pmcs@ (Is there such a list/alias)?
>4.  Send to committers@
> 
> I think I would avoid 2 as this is more an external communication channel.

Well, sure, but "external" is just community we haven't met yet.

> For 1 we would need a list of the IoT projects … I do know some, but by 
far not all and the list on:
> https://projects.apache.org/projects.html?category#iot
> But that list doesn’t seem to be too comprehensive ;-)
> 
> If there’s something like p...@apache.org<mailto:p...@apache.org>, I 
would prefer this but I couldn’t find it …
> but I could swear I had used it for TAC stuff before.

Restricting this to the PMCs seems odd. I suspect you want to target all 
dev and users. The committers@ list seems like a good target, for sure, too.


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

New inter-project Mailinglist i...@apache.org created

[Christofer Dutz]

Hi all,

our new i...@apache.org mailing list has been created 
and is now waiting for subscribers :-)

What do you think would be the best way to advertise this?

  1.  Send an email to each pmc in the IoT sector
  2.  Send an Announce email over the usual announce@ list
  3.  Send to pmcs@ (Is there such a list/alias)?
  4.  Send to committers@

I think I would avoid 2 as this is more an external communication channel.
For 1 we would need a list of the IoT projects … I do know some, but by far not 
all and the list on:
https://projects.apache.org/projects.html?category#iot
But that list doesn’t seem to be too comprehensive ;-)

If there’s something like p...@apache.org, I would 
prefer this but I couldn’t find it …
but I could swear I had used it for TAC stuff before.

Chris

Re: [RESULT] [VOTE] Create a mailinglist for intra-project communication

[Christofer Dutz]

Geee ... Ok ... the i...@apache.org is now queued for creation.

Unfortunately also 9 others too ;-/ .. 
I hope they are not created automatically ... 
and I hope Infra will catch them and drop them (At least I asked them to ignore 
them)

Chris

Am 04.07.19, 16:18 schrieb "Myrle Krantz" :

Just do it.

There's no reason for the rest of us to block you.

: o),
Myrle


On Thu, Jul 4, 2019 at 3:46 PM Christofer Dutz 
wrote:

> Guess now I can change my non-binding vote into a binding one ;-)
> But still I don't have 3 binding votes for it ... so officially there's
> still one binding vote missing ...
> So should I still continue with creating the mailinglist?
>
> Chris
>
    > Am 11.06.19, 10:40 schrieb "Christofer Dutz" :
>
> So the results are:
>
> a) no new list
> 1: Naomi
>
> b) create a tech@a.o<mailto:tech@a.o> list that's expected to be used
> with
> [subject][line][tags] only
> 1: Bertrand (*) (M)
>
> c) create an iot@a.o<mailto:iot@a.o> list
> 6: Chris (M), Andrew, Julian (M), Lars, Myrle (*) , Jorge
>
> (*) are comdev PMCs (As far as I can see and their votes are binding
> comdev votes)
> (M) are people volunteering to be moderators for that particular
> option they voted for.
>
> Guess it's up to a comdev PMC to decide what should be done with this
> result.
> As far as I could see we have two comdev binding votes one for every
> option b and c.
>
> Chris
>
>
>
> Am 10.06.19, 02:09 schrieb "Jorge Betancourt" <
> betancourt.jo...@gmail.com>:
>
> My vote goes to option c.
>
> Best regards,
> Jorge
>
>
>
> 
?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?��[][�]?K�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???��[][�]?K�\?X�?K�ܙ�B�B
>
>

Re: [RESULT] [VOTE] Create a mailinglist for intra-project communication

[Christofer Dutz]

Guess now I can change my non-binding vote into a binding one ;-)
But still I don't have 3 binding votes for it ... so officially there's still 
one binding vote missing ...  
So should I still continue with creating the mailinglist?

Chris

Am 11.06.19, 10:40 schrieb "Christofer Dutz" :

So the results are:

a) no new list
1: Naomi

b) create a tech@a.o<mailto:tech@a.o> list that's expected to be used with
[subject][line][tags] only
1: Bertrand (*) (M)

c) create an iot@a.o<mailto:iot@a.o> list
6: Chris (M), Andrew, Julian (M), Lars, Myrle (*) , Jorge

(*) are comdev PMCs (As far as I can see and their votes are binding comdev 
votes)
(M) are people volunteering to be moderators for that particular option 
they voted for.

Guess it's up to a comdev PMC to decide what should be done with this 
result.
As far as I could see we have two comdev binding votes one for every option 
b and c.

Chris



Am 10.06.19, 02:09 schrieb "Jorge Betancourt" :

My vote goes to option c.

Best regards,
Jorge



?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?��[][�]?K�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???��[][�]?K�\?X�?K�ܙ�B�B

Re: [ANNOUNCE] Welcome Christofer Dutz as new PMC member

[Christofer Dutz]

Hi all,

first of all, thank you for inviting me to the party :-)
I feel deeply honored.

I will do my best to continue my efforts of spreading the word of Apache to 
places they have never heard of it before.

Chris

Am 25.06.19, 07:28 schrieb "Rahul Goel" :

Congratulations Christofer!

On Tue, Jun 25, 2019 at 9:51 AM Swapnil M Mane 
wrote:

> Many congratulations Chris!!
>
>
> - Best Regards,
> Swapnil M Mane
>
> On Tue, Jun 25, 2019 at 12:35 AM Myrle Krantz  wrote:
>
> > Hey all,
    > >
> > Please welcome Christofer Dutz as the newest member of the Community
> > Development PMC.
> >
> > Chris has driven Community Development projects such as representing
> Apache
> > at multiple conferences. He participated in the EU-FOSSA hackathon.  He
> > mentors in the incubator.  He's chairing the EU IoT track.  He
> > has contributed to TAC for years, and is driving TAC for ACEU this year.
> > Chris has taken part in community building at Apache in many ways for
> many
> > years.
> >
> > Thank you Chris, for accepting our invitation to continue your amazing
> work
> > together with us!  I look forward to continuing to work together with
> you!
> >
> > Best Regards,
> > Myrle Krantz
> > PMC Member, Apache Community Development
> >
>


-- 
RAHUL GOEL

Re: [RESULT] [VOTE] Create a mailinglist for intra-project communication

[Christofer Dutz]

Hi Julian,

Well I am also not part of ComDev PMC, but I think that wouldn't be a problem.

Chris

Am 11.06.19, 10:45 schrieb "Julian Feinauer" :

Hi chris,

thanks, the result looks good.
One thing to note is, that although I volunteered to moderate I am no 
ComDev PMC member, so I'm not sure if I am allowed to do so, as someone stated 
that moderation is up to ComDev PMCs.

Julian

Am 11.06.19, 10:40 schrieb "Christofer Dutz" :

So the results are:

a) no new list
1: Naomi

b) create a tech@a.o<mailto:tech@a.o> list that's expected to be used 
with
[subject][line][tags] only
1: Bertrand (*) (M)

c) create an iot@a.o<mailto:iot@a.o> list
6: Chris (M), Andrew, Julian (M), Lars, Myrle (*) , Jorge

(*) are comdev PMCs (As far as I can see and their votes are binding 
comdev votes)
(M) are people volunteering to be moderators for that particular option 
they voted for.

Guess it's up to a comdev PMC to decide what should be done with this 
result.
As far as I could see we have two comdev binding votes one for every 
option b and c.

Chris



Am 10.06.19, 02:09 schrieb "Jorge Betancourt" 
:

My vote goes to option c.

Best regards,
Jorge



?B�CB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?��[][�]?K�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???��[][�]?K�\?X�?K�ܙ�B�B


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

[RESULT] [VOTE] Create a mailinglist for intra-project communication

[Christofer Dutz]

So the results are:

a) no new list
1: Naomi

b) create a tech@a.o list that's expected to be used with
[subject][line][tags] only
1: Bertrand (*) (M)

c) create an iot@a.o list
6: Chris (M), Andrew, Julian (M), Lars, Myrle (*) , Jorge

(*) are comdev PMCs (As far as I can see and their votes are binding comdev 
votes)
(M) are people volunteering to be moderators for that particular option they 
voted for.

Guess it's up to a comdev PMC to decide what should be done with this result.
As far as I could see we have two comdev binding votes one for every option b 
and c.

Chris



Am 10.06.19, 02:09 schrieb "Jorge Betancourt" :

My vote goes to option c.

Best regards,
Jorge