Re: Siren by OpenSSF

[Jarek Potiuk]

I signed up too.

J.

On Wed, May 29, 2024 at 10:43 AM Arnout Engelen  wrote:

> (adding security-disc...@community.apache.org for visibility)
>
> Looks interesting, I signed up.
>
> As this is a post-disclosure channel, ideally we don't really expect to
> learn about new vulnerabilities here, but there's a couple of ways I think
> it could be useful:
>
> For discussions around issues in our own projects:
> * we could monitor they indeed map to disclosures we published and flag
> 'rogue' publications
> * we could learn about how we could improve our messaging
> * we could consider proactively sending our advisories to Siren (like we do
> to oss-security), I'll get in touch with them on whether and how that's
> welcome.
>
> For discussions around issues in our dependencies:
> * perhaps we could use Siren as an extra signal to highlight particularly
> serious issues, as generally monitoring advisories for dependencies has a
> low signal-to-noise ratio (
>
> https://cwiki.apache.org/confluence/display/SECURITY/Dealing+with+security+advisories+for+dependencies
> ),
> so it's not obvious how to do this effectively.
>
>
> Kind regards,
>
> Arnout
>
> On Wed, May 29, 2024 at 4:31 AM Roman Shaposhnik  wrote:
>
> > This seems like a pretty useful service for getting early
> > signals around disclosures and such. Given how many
> > projects in the supply chain they are tracking are from
> > the ASF I wonder if we need to be on a receiving end
> > of it either via security@a.o or some other way?
> >
> >
> https://openssf.org/blog/2024/05/20/enhancing-open-source-security-introducing-siren-by-openssf/
> >
> > Thoughts?
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
> --
> Arnout Engelen
> ASF Security Response
> Apache Pekko PMC member, ASF Member
> NixOS Committer
> Independent Open Source consultant
>

Re: [WG] Workgroups update

[Jarek Potiuk]

Out of those, I'd encourage everyone to also take a look at the advisors
which I think if we collectively execute it right, might make a big
difference on how people are perceiving the ASF.

I personally would like that quite a number of people who are active
members will take on the "advisors" role in some of the PMCs eventually
(and I personally definitely am going to pick a project or two and offer my
help).

In the meantime:

* you can help with clarifying (proposing or commenting) some of the "whys"
(I.e. adding a bit more context and starting points for the advisors to
help explain some of the red-flags to other projects)
https://github.com/apache/comdev-working-groups/tree/main/wg-advisors/why .
We have a few of those - I just made a draft proposal on another
https://github.com/apache/comdev-working-groups/pull/35
* signing up to become an advisor:
https://github.com/apache/comdev-working-groups/blob/main/wg-advisors/advisors.md
* possibly starting to advise projects that you would like to, even today

J..



On Sat, Mar 30, 2024 at 12:20 AM Paulo Motta  wrote:

> I would like to help in the badging working group but I’m currently on
> vacation. I will follow-up in 4 weeks or less. I will join efforts if
> someone else takes on some initial work before then.
>
> On Fri, 29 Mar 2024 at 11:07 Rich Bowen  wrote:
>
> > A month or so ago I started pitching workgroups as a way to organize and
> > make progress on the many pain points around the Foundation.
> >
> > We’ve made a little progress since then, but not a lot of follow-up.
> >
> > The only way that we’re going to have success here is if we build this
> > thing together, and focus on progress, rather than perfection. So I want
> to
> > encourage each of you to think about what single task you can accomplish
> in
> > one of these working groups (or, even better, what’s your idea for
> another
> > group?) in the coming months.
> >
> > So far, here’s what we have:
> >
> > A top-level web page talking about the WGs:
> > https://community.apache.org/workinggroups/
> > 7 proposed WGs:
> >
> > wg-wg - Defining how working groups work, in general.
> > wg-advisors - Advising PMCs on best practice
> > wg-badging - Creation and maintenance of an accomplishment badging system
> > wg-social - Orchestrating local gathering of Apache enthusiasts
> > wg-social-media - Social media
> > wg-website - Maintenance and improvement of the website
> > wg-welcome - Helping projects, and the ASF in general, be more welcoming
> >
> > There was a great deal of discussion on the Advisors WG, but the majority
> > of that was around naming, rather than actually advising projects. I
> think
> > that this is the WG where we can have the highest impact on the
> Foundation
> > as a whole, and I’d really like to see some folks stepping up to do this
> > work, in whatever small ways you can.
> >
> > I also want to encourage each of you to take ownership of this. This
> isn’t
> > *my* effort. It’s ours, collectively, and we must share the ownership of
> it
> > if we’re going to make any progress. If any of you wants to take a more
> > proactive position in any of these WGs, please step forward and do it.
> You
> > don’t need anyone’s permission.
> >
> > As for myself, I am kind of in stealth mode as an Advisor on a couple of
> > projects, and am working on the website as I have time. But this is going
> > to take all of us.
> >
> > —
> > Rich Bowen
> > rbo...@rcbowen.com
> >
> >
> >
> >
> >
>

Re: [WG: Badging] Tooling

[Jarek Potiuk]

Apologies Paulo if that was. I have indeed missed that this is a public
list.
But - for my excuse - I should have taken Airflow as an example because we
discussed it in public lists (and I had not realized it should have been
secret)

So let me re-cast my considerations here:

* Astronomer runs https://www.astronomer.io/champions/ "The Astronomer
Champions Program for Apache Airflow" - with all the trademarks reviews,
and nominative use of Airflow as expected by Trademarks and our policies,
* It's run by Astronomer and it's cool for the community, it has no PMC
involvement at all (besides that we know about it) - to avoid the feeling
that it's a "PMC" thing - some of the people are already posting blogs and
having talks at our "Monthly Town Hall meetings"

This is all cool and great, but we can't make it a PMC "badging" program as
it is not run by the PMC.

Having said that - it would be cool if we have (providing it's "ASF
recognized" - similar badging program for Airflow.

That's the gist of what I wanted to say - and yes, the Airflow example here
is much better as a context for this discussion.

J.




On Sun, Mar 10, 2024 at 3:47 PM Paulo Motta  wrote:

> As a member of the Cassandra community I did not appreciate internal
> project matters being brought to a public mailing list without prior
> consent. This does not help re-establishing trust of the project with ASF
> leadership to work on common projects. Please start a new thread with
> priv...@cassandra.apache.org if you would like to continue this
> discussion.
>
> Going back to the main topic of the working group, I do not think badges
> should exist for ASF members, committers or PMCs for two reasons:
> 1) This will create confusion with ASF roles.
> 2) Badges should celebrate achievements and not roles.
>
> I'm OK with an Advisor badge if they are associated with a concrete
> achievement, and not to indicate a role.
>
> On Sat, Mar 9, 2024 at 6:27 PM Paulo Motta  wrote:
>
> > Hi Jarek,
> >
> > You raised interesting discussion points but I would prefer not to
> discuss
> > specific examples in a public mailing list, since they may spark
> > unnecessary controversy and derail from the focus of the working group.
> >
> > Do you mind summarizing your key considerations without mentioning
> > specific projects or vendors ?
> >
> > Thanks!
> >
> > Paulo
> > On Sat, 9 Mar 2024 at 10:35 Jarek Potiuk  wrote:
> >
> >> I like the idea of having "A" badging system that is seen as "ASF
> >> accepted" that any PMC (at PMC level) or any person (at ASF level)
> >> might opt-in to use
> >>
> >> I think such badging system - providing that it's "ASF generally
> >> accepted" concept that is defined well - possibly adopted from others
> >> like Fedora has this nice property that it will potentially disarm
> >> attempts by the vendors to define their own "badging system" that
> >> might have some properties that are unwanted by the ASF.
> >>
> >> Without judging the intentions - we had this drama about Cassandra MVP
> >>  - which was no more, no less - Cassandra driven badging system that
> >> they defined and PMC wanted to adopt it. IMHO this is what it really
> >> was about. Putting a "label" on people following some process and
> >> conditions, so that those people (and the community) can attach some
> >> value to. That's what the badging system is, and that's what the MVP
> >> program of Cassandra essentially was.
> >>
> >> Again - absolutely without judging the intentions that happened in
> >> Cassandra's case. If we had our own "ASF recognised" badging system,
> >> we could very easily funnel any kind of attempts to do similar badging
> >> program into "Here is the badging system we use in ASF - take this one
> >> and use it, maybe adapt it a bit - within the limits it provides and
> >> you are done". If any stakeholder wants to run their own program -
> >> (say Datastax MVP program for Cassandra) -they can still do it, no
> >> problem.
> >>
> >> But if the PMC wants to do something like that, using something that
> >> is not only recognised in ASF but also potentially can bring some.
> >> synergies (ASF level badges on top of PMC-level ones for example).
> >>
> >> There are really interesting synergies possible. For example - one
> >> could come up with an "ASF Advisor" badge as a way to recognise people
> >> who take part in the other comdev working group initiative - Advisors.
> &

Re: [WG: Badging] Tooling

[Jarek Potiuk]

I like the idea of having "A" badging system that is seen as "ASF
accepted" that any PMC (at PMC level) or any person (at ASF level)
might opt-in to use

I think such badging system - providing that it's "ASF generally
accepted" concept that is defined well - possibly adopted from others
like Fedora has this nice property that it will potentially disarm
attempts by the vendors to define their own "badging system" that
might have some properties that are unwanted by the ASF.

Without judging the intentions - we had this drama about Cassandra MVP
 - which was no more, no less - Cassandra driven badging system that
they defined and PMC wanted to adopt it. IMHO this is what it really
was about. Putting a "label" on people following some process and
conditions, so that those people (and the community) can attach some
value to. That's what the badging system is, and that's what the MVP
program of Cassandra essentially was.

Again - absolutely without judging the intentions that happened in
Cassandra's case. If we had our own "ASF recognised" badging system,
we could very easily funnel any kind of attempts to do similar badging
program into "Here is the badging system we use in ASF - take this one
and use it, maybe adapt it a bit - within the limits it provides and
you are done". If any stakeholder wants to run their own program -
(say Datastax MVP program for Cassandra) -they can still do it, no
problem.

But if the PMC wants to do something like that, using something that
is not only recognised in ASF but also potentially can bring some.
synergies (ASF level badges on top of PMC-level ones for example).

There are really interesting synergies possible. For example - one
could come up with an "ASF Advisor" badge as a way to recognise people
who take part in the other comdev working group initiative - Advisors.
Or even plain and simple "ASF member" badge. Having a few badges on
the ASF level mixed with those on PMC level in a single place
(providing that PMC will start using their own labels) might also be a
way how to bring the PMCs closer to the ASF on more-or-less daily
interactions.

I imagine for example a new contributor asking such a question: "Hey I
see on top of being the ' mentor' label, you have the 'ASF
Advisor' and 'ASF member' - can you explain what it means?"  - If such
labels would be visible, and promoted by the PMC in their
communication, newsletters, it would be a great opportunity to "bind"
the ASF community together.

Of course it won't happen overnight, but starting with "choosing" the
right badging system and making it easy for PMCs and persons to opt in
is absolutely necessary to try it out.

J.

On Sat, Mar 9, 2024 at 2:35 PM Andrew Wetmore  wrote:
>
> Can I have the 'not badging' badge?
>
> On Sat, Mar 9, 2024 at 9:16 AM Gary Gregory  wrote:
>
> > Here is a hopefully entertaining story about gaming a system:
> >
> > A long time ago (not in a galaxy far away), I worked for a company that
> > created an internal $ bug bounty as a major release of our flagship product
> > neared. Someone in QA found a bug that caused the language runtime to
> > incorrectly print to the console integers. That person created one ticket
> > for each of the numbers affected, 1, 2 and so forth until it obviously all
> > went very sideways for that person. Fun!
> >
> > Gary
> >
> > On Sat, Mar 9, 2024, 7:17 AM Paulo Motta  wrote:
> >
> > > Apologies if the previous message sounded snarky - it was late and I
> > > impulsively cherry-picked some excerpts to comment without much second
> > > thought. :-)
> > >
> > > A more constructive attempt:
> > >
> > > 1. I like the principles of the Fedora badging program presented by Rich,
> > > and I think we should adopt them verbatim if they are openly licensed.
> > > 2. I think the "gamification" concern of Gary is actually a feature and
> > not
> > > a bug - I think the goal of a badging program is to motivate people to
> > > contribute more to get more badges. If someone abuses the system to get
> > > badges without deserving them, then this is a problem that should be
> > > addressed if/when it arises.
> > > 3. Sebb does not see a point in badges and I also am not interested in
> > > earning them, but there are many people that do and this could be a good
> > > way to encourage contributions. To me, the target audiences of this
> > program
> > > are primarily new contributors who are not yet committers, and
> > secondarily
> > > seasoned contributors who like to earn or display badges. People who care
> > > less about badges don't need to receive them by just not signing up to
> > the
> > > badging system as Rich said.
> > > 4. It looks like Rich has addressed Gary's privacy consideration but we
> > can
> > > submit the proposal to ASF Privacy before being implemented for
> > additional
> > > review.
> > > 5. I still think projects should opt-in for project-specific badges (ie.
> > > code contributions at project X). If the program is successful, projects
> > > will 

Re: [WG: Sharpeners] Propose: milder name

[Jarek Potiuk]

I liked the Sharpener name. It's been nice to have something "cooler" than
regular term. But I agree having Advisor which needs no explanation and
without any extra words explains the extent to which actions of the Advisor
should be considered is a very good property that might help to promote the
idea much faster and better.

+1 on Advisor.

J.



On Mon, Feb 19, 2024 at 9:30 PM Dave Fisher  wrote:

> Hi Rich,
>
> Please find https://github.com/apache/comdev-working-groups/pull/10
>
> Best,
> Dave
>
> > On Feb 19, 2024, at 12:00 PM, Rich Bowen  wrote:
> >
> > Sounds like you’re in final agreement? Are y’all going to produce a PR
> to swap out terms across the repo?
> >
> >
> >> On Feb 18, 2024, at 4:52 PM, sebb  wrote:
> >>
> >> +1 for Advisor.
> >>
> >> Succinct and accurate.
> >>
> >> On Sun, 18 Feb 2024 at 18:59, Dave Fisher  wrote:
> >>>
> >>> Hi -
> >>>
> >>> Thanks, Gary!
> >>>
> >>> I agree. Advisors is really good. A PMC, or even a single PMC member,
> can ask for advice when they have doubts. and unsolicited advice can be
> ignored if not concise and actionable.
> >>>
> >>> Best,
> >>> Dave
> >>>
>  On Feb 18, 2024, at 8:19 AM, Gary Gregory 
> wrote:
> 
>  Hi All,
> 
>  Based on
> https://github.com/rbowen/comdev-working-groups/tree/main/wg-sharpeners#readme
> 
>  I read:
> 
>  - volunteers who come alongside a PMC to offer an outsider's
>  perspective on the project, and advice to build their community.
>  - subscribe to the project's mailing lists and mostly listen
>  - do not have any authority over the PMC
>  - All feedback must be a polite, positive, actionable suggestion, not
>  merely a criticism or a "you're doing it wrong." You must suggest what
>  the community should do, providing links to policy or best practice
>  documents where applicable. Simply criticising is not welcome.
> 
>  All of this sounds to me like an advisory role where advisory is
>  "having or consisting in the power to make recommendations but not to
>  take action enforcing them."[1]
>  So I'd go with "PMC Advisor". It's not cute or clever, it's even
>  bland, but I understand it, ;-)
> 
>  Gary
>  [1] https://www.google.com/search?q=define+advisory
> 
>  On Sun, Feb 18, 2024 at 4:08 PM Rich Bowen 
> wrote:
> >
> >
> >
> >> On Feb 18, 2024, at 10:02 AM, Gary Gregory 
> wrote:
> >>
> >> I've never heard of someone being called a "sharpener"; I've used a
> >> knife sharpener and a pencil sharpener ;-) ... it feels like a
> stretch
> >> here.
> >>
> >> In general, I prefer names that simply describe intent instead of
> >> cuteness/cleverness, especially in an international context where I
> >> find it beneficial to use words that make sense if you have to look
> >> them up.
> >
> > Cool. Y’all come up with a name, and I’ll swap it out.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>  For additional commands, e-mail: dev-h...@community.apache.org
> 
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [WG: Sharpeners] Proposed: Escalation advice

[Jarek Potiuk]

Yes. We had discussion (and slack conversation) with Rich and I shared some
of the same questions and possible clarifications in the docs (which I will
also propose PRs for in a few days as I am pursuing Biathlon World
Championships this weekend with my wife - in Czech Republic most of the
time :) .

My main points (and PRs to propose) as I understand it (note that this is
my interpretation and further thinkin on how I understand / would like to
see Sharpener program now and likely will turn into proposals of PRs to the
concept):

1) clarify that the escalation and reports are nothing exclusive to
Sharpeners. The escalation described in the document linked to by Rich
should happen is basically  anything, any ASF member notices as a clear
violation of ASF rules - and they should feel obliged to do so if they
see, make comments about to the PMC and get rejected or ignored, nothing
"sharpener specific". This should not be seen as a prerogative, special
privilege, super-power of or anything expected from Sharpeners
specifically. This is what any ASF member should do (and introducing the
Sharpener concept might be a good opportunity to remind members about BTW).

2) I think one of the Goal of Sharpeners (not stated explicitly) is to make
sure that all the conversation initiated around the "ASF way" should happen
in the "devlist" - i.e. the place where for example Board Members looking
at the project will be sure to find. This covers the cases where it's not
clear. My goal here is to make sure that when Sharpener is involved in the
PMC, it does not lessen the Board overlook over the project. It's still
there and if Sharpener will not realise or will not interpret a behaviour
as "wrong" it is still in the hands of Board members to assess the project.
I think the fact that Sharpener is looking at particular PMC should be
noted somewhere - so that - for example - Board member who wants to  review
the project at regular review could see at the history of devlist
conversations which Sharpener started or took part in (simple filter in
ponymail) and will be able to assess on their own if the PMC needs any
action and discussion at the Board level

Why the above? [I think the 2 points above combined are a great way to make
the Board Member's work way easier when reviewing projects, without
delegating the responsibility to the Sharpener to do such a review]. IMHO
the job of Sharpeners is to help and disseminate Apache Way, but not to
take responsibility for the project's conformance and deciding on
thresholds where board action is required (except some obvious cases as
outlined in the escalation document - but this is a regular Member
obligation anyway, not Sharpener in particular, so this is mostly a
different bucket altogether).

3) I also think that indeed - there are those two modes the relationship
PMC <> Sharpener starts (and yes I also plan to do PR on that, because I do
think it needs to be very explicit to explain in the program, how the
relationship starts):

* PMC asks for help when they struggle (or when the board encourages them
to do so). This requires likely to recruit a number of "potential
sharpeners" with listing their interest and willingness to help but IMHO it
also needs a lot of advertising of the whole concept. Very similar case was
with https://whimsy.apache.org/members/mentors - which had a very similar
goal but no-one knows about. And we should learn from that program - i..e.
we as a working group should have a goal to make the program known to PMCs
and idea how to do it if we want this part to be successful. I have few
ideas about it, but it very much depends on the final shape of the whole
program, because there might be different incentives we might think of and
different communication mechanisms that can be used to both - market this
among the PMCs.

* Sharpener asks if they can join the project as Sharpener - which might be
driven by personal interest, existing relationships with the people in the
project or just a genuine need to do "good thing" and spread the things you
believe in in projects that you think might need it (there might be other
reasons as well - I can imagine Sharpeners might do it for example because
they think it's good to learn something about the project and this might be
a cool opportunity to start getting involved), or because they want to
share things they've done to follow "Apache Way" and they see that
experience might be replicated in another project (AKA "lead by example").
Here again I think a lot depends on the final shape of the program
(including the potential incentives and target group of Sharpeners the
program should have).

I think we should also be quite explicit how those relations are NOT set.
For example it should never be that the Board should ask a potential
Sharpener to become one for a specific project because they need someone
there (or at least I think it's not  and should never be the purpose of the
program). Maybe that's implicit, but I think 

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

[Jarek Potiuk]

I have been refraining from commenting so far but I am just about to
catch-up on several other Foundation'y thing and while I generally see it
as a good idea (and I would gladly volunteer my time to sharpen some
projects if I am accepted as a Sharpener) but there are few details in here
that give me some goose bumps. Maybe it's because it's the cultural and
background things (and my inherent inability to be part of (rather than
cooperate with) of anything that looks corporatishly to me. But -
followinareng Rich's comments - I will start from proposed solutions, and
then explain what problem they solve rather than stating only the problems
I see.

Sorry for the long mail, but I thought about it for last few days to wrap
my head around it, and well, I think it's worth spelling out what I came up
with. If it's too long for you to read, then feel free to ignore it as
well, maybe it's just my rambling.

So far - I think, maybe I missed it as I was focused on some
security/Airflow issues I had been deeply involved with - there was no
discussion on how and when and initiated by whom a Sharpener chooses to
join the PMC and what is the relation of PMC - Sharpener - Board and
whether and how Board is involved in the process. Who and when originates
sharpener joins the project is not (or I could not find.it) defined. I am
not sure what was the intention (both to start with and what it might turn
into in the future for that part of the relation, but here is what I think
about it.

Proposed solutions (at least this would be the Sharpeners I'd gladly join):

* Sharpeners should be a group of people who should be ready to join PMCs
to help them but not proactively choose projects and not (God forbid) be
assigned by the Board to some projects

* Sharpeners **might** if they want, offer their help to the PMCs directly
if they happen to or stumble upon the notion that project might struggle
with something (various ways, but not directed, nor asked by the Board) -
especially when Sharpener has some relationship with the project / PMC /
people (but no corporate interest/ allegiance etc. ). But this should be
accidental, purely based on existing relations and serendipity of other
conversations happening.

* The initiative to reach out to Sharpeners should come from the PMC -
almost exclusively. The board (with regular project review) might suggest
to the PMC that they consider choosing /asking for Sharpener to help them,
it should also be advertised and reminded regularly - possibly as part of
reminding about reports, that PMCs can reach out if they feel they need
help. And they should be able to choose the person from Sharpener's group
who is available to help and whom they can trust.

* We should aim to have quite a significant number of Sharpeners from
various cultures and backgrounds. so that there is a high chance if PMC
struggles, they will find a sharpener they know about or had interacted
with in the past and they can trust they can cooperate and get useful
relationships there.

* most important - Sharpeners should **NEVER** report anything to the board
- it should be neither expected nor even hinted they could. Creating a
special place for them where they could do it is a BIG HAIRY NO for me.
They should be exclusively seen (by the PMC) as helpers, and possibly
trigger conversations in the PMC when they see conversation is needed. Not
as someone who might report something to the board. They could - same as
any other person in the project - be asked during a regular review in case
the board member has questions about what's going on and start asking
questions. Ideally - the projects with sharpener on board, should be easier
to review by the board member, they could just look at the conversations
the sharpener takes part in - those will be the potential problematic
cases. Since sharpener will make sure those conversations happen on the
devlist/private (and will do everything to bring them in), the job of board
member should be much easier. Board should treat projects with Sharpener as
ones where they can just be sure that Sharpener will trigger the right
conversations focusing exclusively on "Apache Way". Simply speaking the
Sharpeners should not "do" the job of current Board members, they should
just make it a lot easier and more obvious for board members to see
problems coming.

Now - what problem does my proposed solution solve?

* Mainly, trust in intentions, and avoiding seeing the Sharpener as a
board "punishing hand" and "policeman". There are a number of statements
about that in the current proposal, but the structure where there is a
report to the board is 100% opposite of that IMHO. Maybe it's the communist
past that influences my impression and thinking - but we - people from
Eastern Europe know very well the case where your "friends" and "peers"
turned out to be confident that they were spying and got "reports" on you.
I know it's absolutely not the case here (we are not talking about evil
Empires and 

Re: ASF booth at OpenSource Experience Paris

[Jarek Potiuk]

Fantastic. Good to hear all that Ryan :)

On Fri, Dec 15, 2023 at 4:30 PM Ryan Skraba  wrote:
>
> Hey all, I just wanted to report back to the community about this event.
>
> I was only there for one of the two days.  There were about 5 of us,
> which was satisfying because some of us could stay at the table while
> others visited the expo or met with others during the day.
>
> For an "Open Source Experience", it's a bit surprising how many
> attendees were only peripherally aware of the Foundation (although the
> HTTP server had pretty good recognition).  There were many students,
> but this year there were also quite a few people in "reconversion" --
> in the process of changing their career towards software and tech.
> People are generally interested in contributing, especially to grow
> their experience. Free stickers are a really nice way to talk about
> how wildly different the software projects are and some of the common
> ground that the ASF provides between them in terms of tools and
> governance.
>
> Most of the questions we had were around first-time contributions, and
> how *my* employer earns money from open source (once it was clear that
> the ASF is not my employer).  For the attendees that were familiar
> with the ASF, I pushed the Community over Code Europe 2024
> conference[1], with some pretty positive feedback!
>
> Thanks so much to Olivier, Hervé, JBO, Ismael for being there!
>
> Ryan
>
> [1]: https://eu.communityovercode.org/blog/cfp-open/ "CFP closes
> January 12, submit submit submit"
>
> On Tue, Dec 5, 2023 at 10:11 AM Ismaël Mejía  wrote:
> >
> > Hi,
> >
> > I will be able to help on the first day of the event. Olivier can you
> > please help me get a badge.
> >
> > Note that I had already registered as an assistant with my iemejia@ apache
> > id, I hope that's not an issue to change it, I want the luxury of access to
> > coffee :)
> >
> > See you tomorrow!
> > Ismaël
> >
> >
> > On Wed, Oct 4, 2023 at 9:28 AM Olivier Heintz 
> > 
> > wrote:
> >
> > > Hi,
> > >
> > > Open Source Experience in Paris  on 6 & 7 December 2023 is an event for
> > > the European open source community (as they said on the web site)
> > >
> > > For me, it is the French annual Open Source event.
> > >
> > > On this event there are a large part for Company working on Open Source
> > > and a small part for  non profit organization (association/foundation/...)
> > > named associative village
> > > On first step I have asked to have a ASF booth on associative village and
> > > after selection we have been selected !
> > >
> > > This booth is free but it's a exchange contract between the booth and the
> > > future ASF communication action for this event.
> > > I have some question to the Event organization.
> > > I can send the contract proposal to anyone want read it (it's in french)
> > >
> > > Olivier
> > >
> > >
> > >
>
> -
> 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: FOSDEM 2024

[Jarek Potiuk]

So as Sharan corrected me (thanks)- it's for stands. not talks (facepalm)
Sorry for the alarm!

J.



On Thu, Nov 9, 2023 at 1:53 PM Jarek Potiuk  wrote:

>
> Also if you wanted to submit a talk. I just realized after looking at
> FOSDEM website after this message that FOSDEM moved their CFP submission
> deadline from 20th of November to *10th of November* (i.e. *TOMORROW*)
> https://fosdem.org/2024/news/2023-11-01-amendment-stands-cfp/
>
> I had a reminder set for this weekend, and from the experience I know many
> people submit proposals in the last few days of CFP, so if you also
> planned to do it next week, better hurry.
>
> J.
>
>
> On Thu, Nov 9, 2023 at 12:15 PM Sharan F  wrote:
>
>> Hi Roman
>>
>> Great to hear you will be there!
>>
>> I haven't created a wiki page yet as I have applied for an ASF booth at
>> FOSDEM but haven't had any confirmation that we have got one yet.
>>
>> They have announced the accepted Devrooms but not which Stands/booths are
>> accepted so we need to wait until the 20th November to find out.
>>
>> Thanks
>> Sharan
>>
>>
>>
>>
>> On Thu, 9 Nov 2023, 10:50 Roman Shaposhnik,  wrote:
>>
>> > Hi!
>> >
>> > I remember we typically have a wiki page for coordinating
>> > things around FOSDEM -- I just forgot the URL :-( Little help?
>> >
>> > Also, I'll definitely be there and also plan to be at the State of
>> > Open CON in UK after that.
>> >
>> > Thanks,
>> > Roman.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> > For additional commands, e-mail: dev-h...@community.apache.org
>> >
>> >
>>
>

Re: FOSDEM 2024

[Jarek Potiuk]

Also if you wanted to submit a talk. I just realized after looking at
FOSDEM website after this message that FOSDEM moved their CFP submission
deadline from 20th of November to *10th of November* (i.e. *TOMORROW*)
https://fosdem.org/2024/news/2023-11-01-amendment-stands-cfp/

I had a reminder set for this weekend, and from the experience I know many
people submit proposals in the last few days of CFP, so if you also
planned to do it next week, better hurry.

J.


On Thu, Nov 9, 2023 at 12:15 PM Sharan F  wrote:

> Hi Roman
>
> Great to hear you will be there!
>
> I haven't created a wiki page yet as I have applied for an ASF booth at
> FOSDEM but haven't had any confirmation that we have got one yet.
>
> They have announced the accepted Devrooms but not which Stands/booths are
> accepted so we need to wait until the 20th November to find out.
>
> Thanks
> Sharan
>
>
>
>
> On Thu, 9 Nov 2023, 10:50 Roman Shaposhnik,  wrote:
>
> > Hi!
> >
> > I remember we typically have a wiki page for coordinating
> > things around FOSDEM -- I just forgot the URL :-( Little help?
> >
> > Also, I'll definitely be there and also plan to be at the State of
> > Open CON in UK after that.
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

Re: VP Conferences changes

[Jarek Potiuk]

Thanks Rich for all the spirit of the Community Over Code (AKA ApacheCon).

Sharing my personal experiences, I am not sure how much you were the
"Spirit" of the EU conference in Berlin, that was my first "ApacheCon"
experience - but that is where I got the "Community" vibes. This is where
(and because of what I experienced at the conference) I decided to dedicate
a lot of my effort, time into getting involved with the ASF more. Simply
because I saw why the people who were there - actually wanted to be in the
same place. Not because the number of attendees, amount of money raised,
number of sponsors or amount of sponsorships, quality of the food etc.
These are absolutely necessary, But I think what was the most important
"spirit" of the event and true passion of the organizers to build
thriving communities of people who genuinely want to be together, grow and
especially - bring new people in and feel them both welcome and creating
the space for those new people to bring their own vision and be absolutely
opened to help those people to realise their vision (like me in 2019).

I have not been even PMC member yet in 2019, yet I was thrilled by
organizers willing to add me to  "pre-event" schedule (where I talked about
how we are starting to build welcoming community in Apache Airflow - I
remember the surprise that people actually showed up in big numbers - it's
been a full house with people sitting on the stairs - a day before the
actual conference and opening. That was mind-boggling - as a long time
conference organizer, I've never seen anything like that. Also another
experience from 2019 - when I found a place/company that helped us to
organize "first time contributor's workshop", the organizers of the
ApacheCon Berlin added information about the workshop and prominently
displayed and announced it in all possible channels (no questions asked, no
sponsoring or any other discussions involved - simply seeing the value in
the community spirit, cooperation and building various communities - by
partnership, cooperation, accepting ideas and leadership of others in
running those and most importantly open mind). Thanks to that I had -
together with a dear friend of mine who is also a committer  - a full house
again with some of the relations and contributors who are part of the
communiity of our project till today.

I read your word in other threads and planners about you not "running" the
conference personally and passing it to those who actually "do" run it for
a few years". But at least from my experience - and I think out of modesty
- I believe you vastly underestimate the "spirit" of the event you
personally created. At least from my past experience, logistics,
organisation, etc. can be easily "bought". The spirit, willingness of
cooperation, true passion for building communities and letting people grow
around you is somethign that can never be "bought" for any sponsorship
money and cannot be "marketed".

I am - sadly and for personal reasons - not involved in organizing the EU
event next year, but I hope the fantastic team of organizers that started
it will have an opportunity to realise their vision and put the "spirit" in
the conference next year. I am curious to see how it plays out without you
as the VP conferencing and how your "spiirt" space will be filled.

J.


On Wed, Nov 8, 2023 at 11:42 PM Kanchana Welagedara 
wrote:

> Dear Rich,
>
> With reminiscing of helping out to organize ApacheCon Asia 2006 Asia ( Sri
> Lanka ), my first ever ApacheConf experience, let me write this you .
>
> Your dedication, guidance and tireless efforts have made a profound impact
> on Apache community . Apache conferences have flourished and have become
> not just events but vibrant gathering of like-minded individuals passionate
> about Apache software .
> Your commitment to fostering the an inclusive and environment has created
> an atmosphere where participants are formed and knowledge is shared .
>  Thank you for outstanding services as the VP of conferences.
>
> Cheers,
> Kanchana
>
>
>
> On Wed, Nov 8, 2023 at 10:18 AM Dave Fisher  wrote:
>
> >
> >
> > > On Nov 8, 2023, at 8:06 AM, Owen Rubel  wrote:
> > >
> > > "So rather than worry about these sort if artefacts of
> > institutionalisation
> > > or what bad KPIs \& wrong incentives can drive in a corporate world --
> > lets
> > > just make sure together that these conferences are what we want."
> > >
> > > I kind of figured that was the point of speaking up; to let you know
> how
> > > vendor based conferences end up pushing out engineers.
> >
> > You are not “wrong”, but within the ASF ecosystem this large problem
> > already exists with some of our projects having vendor run “Summits”.
> It’s
> > a different problem than who is managing Community over Code production.
> > It’s a community health problem and an example of Foundation educational
> > and governance improvements.
> >
> > How can ComDev help ASF PMCs improve on that existing, very complex, and
> > 

Re: Valid categories for projects.apache.org

[Jarek Potiuk]

I've already written about it in one of the previous talks -  I think that
we can have a good approximation of categories from the "Community Over
Code".

Except few language-specific categories there (Groovy which is clearly cut
by "language" not category) pretty much  tracks there are pretty nice
"categories" of the software we have in the ASF - and they are "important
enough" that someone took the lead and decided to volunteer thinking that
it's worth to "carve it out" as an "entity" at Community over Code and
managed to communicate their intentions to speakers who responded to CFP
understanding what the "track category" is about.

There are few generic (Incubator, Community, Sustainability, Server Side
chat with infra) that apply to various "categories" so we can leave them out

>From the https://communityovercode.org/schedule/

* Search
* Streaming
* Big Data Storage
* Big Data Compute
* API/Microservices
* Cloud and Runtime
* Performance Engineering
* Web Servers (renamed from Tomcat and Httpd -> this is my attempt to
categorise it similarly to others rather than by names of Projects/PMCs )
* Fintech
* Data Engineering
* Content Wrangling
* Geospatial
* Frameworks
* Internet of Things

Sounds to me like a nice set of categories that seem current and even have
a chance to be regularly refreshed  - potentially we could adopt it as a
way to see if there are significant changes/new categories.

J

On Thu, Sep 7, 2023 at 1:39 PM sebb  wrote:

> As for languages, some DOAPs currently contain categories that don't
> agree with the current valid list.
>
> The outliers are:
>
> data-management-platform
> distributed-sql-database
> education
> ftp
> geospatial
> graphics
> hadoop
> IDE
> identity-management
> identity-provisioning
> integration
> Kerberos
> observability
> SDK
> search
> templating
> virtual-machine
>
> I think some of the above could be added, possibly under a more general
> heading.
> For example, graphics could make a reasonable category.
> However, distributed-sql-database and Kerberos seem too specific.
> ftp is probably part of network-client/network-server
>
> Plus the following, which are all languages.
> I think they can safely be disallowed as categories:
> C
> C++
> Go
> Groovy
> HTML
> Java
> PHP
> Python
> Regexp
> SQL
>
> Thoughts?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Drop list of languages and categories?

[Jarek Potiuk]

Fully Agree.

I looked at those when I recently learned about DOAP and I hoped they will
give some more information, yet all my hope was gone when I looked at them.

J,

On Wed, Sep 6, 2023 at 3:09 PM sebb  wrote:

> It's a bit of a pain to maintain two copies of the lists of languages
> and categories.
>
> Seems to me that the pages
> https://projects.apache.org/categories.html
> https://projects.apache.org/languages.html
> don't provide anything that is not available from the drop-down list
> on the DOAP creation form.
>
> I think they should be dropped.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Incorrect categories in DOAPs

[Jarek Potiuk]

+1

śr., 6 wrz 2023, 14:03 użytkownik  napisał:

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

Re: RFC: many PMCs have not provided DOAPs

[Jarek Potiuk]

Thanks Sebb. Very useful/much appreciated.

> If they are independent products - i.e. can be used independently -
then I would say yes.

Nope. They are "extensions" of the "core" airflow. You cannot use them
without "some" version of airflow installed as well.

> Seems to me that individual providers are a level of detail that are
best documented within the project itself.

Agree

> However it might make sense to add a generic provider DOAP that
describes the role that providers play in the ecosystem.

I like that idea. Less hassle, less "entities" to worry about and we anyhow
release them together in "bulk".

Question:

I see that we have "Release name" in releases that could allow us to group
all releases for the same providers. Maybe it would be a good idea to make
some "artifact identifier" not only name ? Or maybe the "name" is not
really something that is used anyway and we could repurpose it for the
provider name - for example "Apache Airflow Provider Google" for example
for all "Google provider" releases? One worry I have is about the sorting
order when releases will be displayed on the "projects" page - it would be
grouped if they could be put together and we could see all the releases of
a provider together - rather than all of them mixed together.

J.



On Wed, Sep 6, 2023 at 12:29 PM sebb  wrote:

> On Wed, 6 Sept 2023 at 09:13, Jarek Potiuk  wrote:
> >
> > We just added DOAP for airflow (core project) and I am planning to add
> > release information for it automatically as well now when I see it
> working.
> >
> > I have a question about good practices though, before I make the next
> step
> > - which is automating generation of all the DOAPs of ours.
> >
> > In the Apache Airflow PMC we are regularly releasing ~ 90 packages.
> Almost
> > all of them come from the same monorepo and are technically separate
> > artifacts / releases and they have their own releases (each of the
> packages
> > follows SemVer versioning and they versioning is independent in each
> > package).
> >
> > I believe the idea of DOAP is that if a PMC releases more than one
> project,
> > each of them should have its own DOAP?
>
> If they are independent products - i.e. can be used independently -
> then I would say yes.
>
> However if they are effectively part of the same product then it is less
> clear.
>
> So for example Commons components can all be used independently and
> have individual DOAPs
> Likewise HttpComponents.
> I'm not sure why HTTPServer singles out mod_ftp; I'm not sure it would
> be useful to include all the add-on HTTP modules.
>
> > So I am thinking about adding (automatically) DOAPs for all the ~90
> > packages (we have airflow core + airflow providers). Is that a good idea
> ?
>
> Seems to me that individual providers are a level of detail that are
> best documented within the project itself.
>
> The purpose of the site is to provide information about ASF projects.
> Would it help the general public to have all these extra details?
>
> However it might make sense to add a generic provider DOAP that
> describes the role that providers play in the ecosystem.
>
> > I believe it will inflate and impact the total numbers (out of the
> sudden,
> > Python will become the strong second in the pie-chart here
> > https://projects.apache.org/ and we will have almost 90 "Apache Airflow
> > Provider " projects in the various lists produced by `
> > projects.apache.org" - pretty much dominating some categories (you can
> see
> > all the provider packages we release here:
> >
> https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml
> > )
> >
> > Is that something that we consider as "good practice"  and expected to
> > happen in this case? Will that cause problems for anyone ?
>
> No and yes
> ;-}
>
>
> > J.
> >
> >
> > On Wed, Sep 6, 2023 at 9:32 AM Martijn Dashorst <
> martijn.dasho...@gmail.com>
> > wrote:
> >
> > > On Tue, Sep 5, 2023 at 6:45 PM  wrote:
> > >
> > > > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote:
> > > > > I doubt it will ever be possible to ensure that fields like
> releases
> > > > > are kept up to date.
> > > >
> > > > It appears that we have *some* projects that update the doap file as
> > > > part of their release runbook. But, yeah, not all of them.
> > > >
> > >
> > > Wicket does it as part of the site generation:
> > >
> > > This file in our git repository:
> > >  https://github.com/apache/wicket-site/blob/asf-site/doap.rdf
> > >
> > > Gets transformed by jekyll into this for publishing:
> > > https://wicket.apache.org/doap.rdf
> > >
> > > So whenever we update the site for a new release, the doap and atom RSS
> > > feed get updated as well.
> > >
> > > Martijn
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: RFC: many PMCs have not provided DOAPs

[Jarek Potiuk]

We just added DOAP for airflow (core project) and I am planning to add
release information for it automatically as well now when I see it working.

I have a question about good practices though, before I make the next step
- which is automating generation of all the DOAPs of ours.

In the Apache Airflow PMC we are regularly releasing ~ 90 packages. Almost
all of them come from the same monorepo and are technically separate
artifacts / releases and they have their own releases (each of the packages
follows SemVer versioning and they versioning is independent in each
package).

I believe the idea of DOAP is that if a PMC releases more than one project,
each of them should have its own DOAP?

So I am thinking about adding (automatically) DOAPs for all the ~90
packages (we have airflow core + airflow providers). Is that a good idea ?
I believe it will inflate and impact the total numbers (out of the sudden,
Python will become the strong second in the pie-chart here
https://projects.apache.org/ and we will have almost 90 "Apache Airflow
Provider " projects in the various lists produced by `
projects.apache.org" - pretty much dominating some categories (you can see
all the provider packages we release here:
https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml
)

Is that something that we consider as "good practice"  and expected to
happen in this case? Will that cause problems for anyone ?

J.


On Wed, Sep 6, 2023 at 9:32 AM Martijn Dashorst 
wrote:

> On Tue, Sep 5, 2023 at 6:45 PM  wrote:
>
> > On Tue, 2023-09-05 at 17:19 +0100, sebb wrote:
> > > I doubt it will ever be possible to ensure that fields like releases
> > > are kept up to date.
> >
> > It appears that we have *some* projects that update the doap file as
> > part of their release runbook. But, yeah, not all of them.
> >
>
> Wicket does it as part of the site generation:
>
> This file in our git repository:
>  https://github.com/apache/wicket-site/blob/asf-site/doap.rdf
>
> Gets transformed by jekyll into this for publishing:
> https://wicket.apache.org/doap.rdf
>
> So whenever we update the site for a new release, the doap and atom RSS
> feed get updated as well.
>
> Martijn
>

Re: (NuttX) Re: Missing DOAP file

[Jarek Potiuk]

I think we could take categories we have for Community Over Code tracks: we
have both Data Engineering and IOT second time in a row and they are pretty
distinct from others.

J,

On Wed, Sep 6, 2023 at 12:04 AM sebb  wrote:

> On Tue, 5 Sept 2023 at 18:38, Rich Bowen  wrote:
> >
> > On Tue, 2023-09-05 at 14:29 -0300, Alan C. Assis wrote:
> > > Hi Rich,
> > >
> > > Thank you very much for let us to know about it.
> > >
> > > Before you create the DOAP, could you please include the Category:
> > > RTOS or IoT ?
> > >
> > > NuttX doesn't fit in any of existing categories: Big Data, Build
> > > Management, Cloud, etc.
> >
> >
> > Hey, folks, NuttX has requested the addition of a new category or
> > categories for projects.apache.org. Are there any objections to me
> > creating this?
>
> I don't see why not.
>
> AFAIK, there aren't any formal rules for what categories are allowed,
> but it would be good to keep the categories as general as possible.
> If the categories are too specific, there is a danger that closely
> related projects end up in different categories.
>
> Note that a project can be added to multiple categories.
>
> > This seemed a larger, less reversible step than updating data, so I
> > wanted to be sure to get some broader feedback.
> >
> > Thanks.
> >
> > --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: (NuttX) Re: Missing DOAP file

[Jarek Potiuk]

Would it also be possible to add "Data Engineering" ? I chose BigData for
Airflow as the "closest" match but I would like to change it to "Data
Engineering" if possible.

On Tue, Sep 5, 2023 at 7:38 PM Rich Bowen  wrote:

> On Tue, 2023-09-05 at 14:29 -0300, Alan C. Assis wrote:
> > Hi Rich,
> >
> > Thank you very much for let us to know about it.
> >
> > Before you create the DOAP, could you please include the Category:
> > RTOS or IoT ?
> >
> > NuttX doesn't fit in any of existing categories: Big Data, Build
> > Management, Cloud, etc.
>
>
> Hey, folks, NuttX has requested the addition of a new category or
> categories for projects.apache.org. Are there any objections to me
> creating this?
>
> This seemed a larger, less reversible step than updating data, so I
> wanted to be sure to get some broader feedback.
>
> Thanks.
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Releasing with lazy consensus

[Jarek Potiuk]

> "Bulk" voting is something I have heard before. Certainly can be a
solution
*if* the packages don't depend on each other. Otherwise I cannot see how it
helps with the cases I shared earlier. That is, `log4j-core` needs to be
released first so that `log4j-bom` can be updated and released. Put another
way, both can't be released simultaneously.

Oh yeah. Those we have a fair share of. Even in the last release we had a
chicken-egg problem of dependencies and we had to split and manually tweak
the release process - that was a bit of a headache.
Maybe what will help - in essence with Airflow we do keep two "separate"
release trains

a) core airflow <- single package release
b) providers <- this is where the bulk voting happens (and here often
happens that there are cross-dependencies between them - but when you
release them together it's fine)

But sometimes we release certain "providers" first even if they are not
"usable" - precisely so that the later "core airflow" release makes use of
them. So "smart" splitting the releases might also help.

J


On Fri, Sep 1, 2023 at 10:25 AM Volkan Yazıcı  wrote:

> Thanks for sharing insights from the Airflow land, much appreciated.
>
> "Bulk" voting is something I have heard before. Certainly can be a solution
> *if* the packages don't depend on each other. Otherwise I cannot see how it
> helps with the cases I shared earlier. That is, `log4j-core` needs to be
> released first so that `log4j-bom` can be updated and released. Put another
> way, both can't be released simultaneously.
>
> On Fri, Sep 1, 2023 at 9:24 AM Jarek Potiuk  wrote:
>
> > 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
&g

Re: Releasing with lazy consensus

[Jarek Potiuk]

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 voting. Once that is done,
> waiting another 72 hours for `log4j-bom` feels like a waste of time.
> Similarly, `log4j-changelog` is an internally used tool, yet we need to
> publish it to Maven Central and such. Wouldn't it be possible to release
> such projects (e.g., `log4j-bom`, `log4j-changelog`) with lazy voting? That
> is, *"unless there are objections within 24 hours, I'll assume a lazy
> consensus, and release it".* Can the Release Policy
>  and/or the Voting
> Process
>  accommodate such a
> practice?
>

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

[Jarek Potiuk]

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
> 
> 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: Skill based groups at the ASF

[Jarek Potiuk]

I think it's a  great idea.

Though I think the scope of it is probably a bit too open-ended. I
think the right thing to do here is not "let's have guilds" but "let's
make it easy to discover, join and participate in those guilds we have
(and create new ones)".

I think we already have some guilds, but they are not easy to discover
and understand that they are actually there already. Those are just a
few I participate in:

* bui...@apache.org
* legal-disc...@apache.org
* plann...@apachecon.com
* public-affairs-priv...@apache.org
* bo...@apache.org

Those are all really the "guilds" you are talking about - people
interested in the subjects that often exchange information about the
area they are interested in.
Probably there are more I am not aware of / not participating in.

My question is - are those easy to find? Do members/committers who are
not members know they can join and participate in them ? Do they know
how to discover them among the few hundreds mailing lists they can
subscribe to?

I am not sure.

It took me personally a number of months to discover some of those and
realise that I can be (possibly?) helpful in those groups and that
there are things that are interesting there for me. Some of those I
had no idea about that it's ok for me to subscribe to (board@ which I
learned about when I was appointed as board candidate, planners@ when
I was thinking "should we make another conference in EU?" - which I am
now one of the chairs. Maybe that's ok. But maybe not - maybe we need
something to advertise and publish those existing guilds to everyone
in the ASF. Not sure. There is a balance on spamming people and
passing them relevant information, so it's easy to "over-do" it.

So maybe (just maybe?) the scope of this idea should be "how do we
make it easier for everyone to discover, join and participate in those
guilds that are already there and encourage other guilds to be
created" ?

Just my 3 cents,

J.

On Mon, Aug 7, 2023 at 8:06 PM Christian Grobmeier  wrote:
>
> Hi
>
> On Mon, Aug 7, 2023, at 20:01, Drew Foulks wrote:
> > Hi All!
> >
> > I'd like to submit an idea for an effort that I'd like to undertake / see
> > undertaken here at the foundation -- I've taken to calling them guilds for
> > lack of a better name, which are essentially project independent expert
> > groups that help in a specific capacity (builds, writing, websites, etc) to
> > help elevate solutions from the TLP level to the Foundation level.
> >
> > Feedback is appreciated.
>
> I love this idea. I was often thinking "I would like to do $x" but did not 
> know what project would need this skill at this point. This could be fun.
>
> Christian
>
> -
> 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: [DRAFT] Email to all PMCs or Committers

[Jarek Potiuk]

+1. Looks way better.

On Fri, Aug 4, 2023 at 3:21 PM Christofer Dutz
 wrote:
>
> 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:
> > > > 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 

Re: [DRAFT] Email to all PMCs or Committers

[Jarek Potiuk]

Few comments:

* make it shorter
* add TL;DR; explaining in one paragraph what it is about, what effect
it will have on those who receive it
* add - immediately after that - mentioning that while the change is
coming by default to everyone, everyone has a way to go back easily
(and link to a doc explaining how - step-by-step very straightforward,
with an example of .asf.yml to copy
* all the rest - why you are doing it, the context etc. while
interesting and super important for you and necessary to add should be
in a clear section which is marked as "you do not need to read it -
only if you are interested".

All those comments from someone who writes even longer emails than you
so, take it with a grain of salt.

J.

On Fri, Aug 4, 2023 at 11:13 AM Gilles Sadowski  wrote:
>
> Hello.
>
> Sorry to be somewhat off-topic but it relates to the message contents...
> See inline comment.
>
> Le ven. 4 août 2023 à 10:43, Christofer Dutz
>  a écrit :
> >
> > 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.
>
> Pointedly, GitHub does require "yet another login".
> Without registering with GH, I can only look (i.e. read the comments) but
> not participate (i.e. write a comment).
>
> >
> > 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.
>
> Again, going through GH contradicts the "participate [...] without
> requiring any form of login [...]".
>
> Regards,
> Gilles
>
> >
> > 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

-
To unsubscribe, 

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

[Jarek Potiuk]

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

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

[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

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

[Jarek Potiuk]

back full circle :)

On Mon, Jul 31, 2023 at 7:08 PM  wrote:
>
> On Mon, 2023-07-31 at 17:40 +0200, Jarek Potiuk wrote:
> > Hmm,
> >
> > Is it possible to create a repo there then (apachecon-eu - until we
> > rename the group) - I tried to create one with boxer -
> > https://gitbox.apache.org/boxer/?action=newrepo but it's greyed-out.
> >
> > Or I guess I need more karma for that one?
>
>
> Nope, it's greyed out for me too. I would suggest opening an infra
> ticket.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[Jarek Potiuk]

Hmm,

Is it possible to create a repo there then (apachecon-eu - until we
rename the group) - I tried to create one with boxer -
https://gitbox.apache.org/boxer/?action=newrepo but it's greyed-out.

Or I guess I need more karma for that one?

J.


On Mon, Jul 31, 2023 at 4:18 PM  wrote:
>
> On Mon, 2023-07-31 at 15:51 +0200, Jarek Potiuk wrote:
> > Following up with that after short holidays - how can I (and others
> > from the Community over Code EU) get added to the "apachecon" group
> > so
> > that I can create the repository and have "committer" access to it?
> >
> > Do I need a JIRA ticket or just karma granted by someone ? I can
> > provide a list of ASF members to add there as a good start.
> >
>
>
>
> You are in fact already in that group.
>
> https://whimsy.apache.org/roster/group/apachecon?type=LDAP%20Auth%20Group
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[Jarek Potiuk]

Following up with that after short holidays - how can I (and others
from the Community over Code EU) get added to the "apachecon" group so
that I can create the repository and have "committer" access to it?

Do I need a JIRA ticket or just karma granted by someone ? I can
provide a list of ASF members to add there as a good start.

On Mon, Jul 10, 2023 at 3:38 PM Jarek Potiuk  wrote:
>
> Yep. That would be perfect.
>
> On Mon, Jul 10, 2023 at 3:29 PM Rich Bowen  wrote:
>>
>> We could also put something under the Apachecon ldap group, which I am
>> thinking of renaming to conferences or events. That might be a better match?
>>
>> Shosholoza,
>> Rich
>>
>>
>> On Sun, Jul 9, 2023, 02:28 Jarek Potiuk  wrote:
>>
>> > Sure. if we have "apachecon-*" (and possibly renamed). That would be the
>> > best approach.
>> >
>> > No problem with waiting until Rich is back.
>> >
>> > J.
>> >
>> >
>> > On Sun, Jul 9, 2023 at 7:57 AM Willem Jiang 
>> > wrote:
>> >
>> > > FYI， ApacheCon Asia conference website[1] uses Hugo with a customer
>> > > theme[2].
>> > >
>> > > [1]https://github.com/apache/apachecon-acasia
>> > > [2]
>> > https://github.com/apache/apachecon-acasia/tree/master/themes/apachecon
>> > >
>> > >
>> > > Willem Jiang
>> > >
>> > > Twitter: willemjiang
>> > > Weibo: 姜宁willem
>> > >
>> > > On Sat, Jul 8, 2023 at 7:35 PM Jarek Potiuk  wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > > > it might be simpler to manage if we used this PMC instead -
>> > although
>> > > > > > that requires some consensus from this PMC first to own something
>> > > that
>> > > > > > really belongs to conferences.
>> > > > >
>> > > >
>> > > > Yeah. That's what I am really looking for :).  I would also be fine to
>> > > > create
>> > > > a new group ? PMC? for that if ComDev is not the right place. Maybe
>> > there
>> > > > are ways to set up other "entities" for the ASF structure that could
>> > > serve
>> > > > the purpose ? I do not (yet) know all the options - but I believe PMC
>> > is
>> > > not
>> > > > the only option to have a separate "LDAP group".
>> > > >
>> > > > > One note: do you *specifically* want to copy the ComDev site repo?
>> > Or
>> > > > > > do you want to start with the infra-supported (but simpler design)
>> > > >
>> > > >
>> > > > Not really. We can start from scratch, I was referring more to the
>> > > > integrations
>> > > > that we get from INFRA: .asf.yaml, emails sent to specific discussion
>> > > lists
>> > > > we
>> > > > can customize - generally following best practices there.
>> > > >
>> > > >
>> > > > >
>> > > > My experience with both Hugo and Pelican is that Hugo is easier to
>> > > > > customise.
>> > > > >
>> > > >
>> > > > Yes we also prefer Hugo. Airflow Summit Website - prepared entirely by
>> > > the
>> > > > Software
>> > > > Guru team - our producers - is based on Hugo, so that would be our
>> > > > preference as well.
>> > > >
>> > > > https://github.com/softwareguru/airflowsummit-website
>> > > >
>> > > >
>> > > > >
>> > > > > > template repo they recommend for new projects?
>> > > > > >https://github.com/apache/template-site
>> > > > >
>> > > > > I don't think that is production ready.
>> > > > >
>> > > >
>> > > > We have quite a lot of time before our website will be public (at the
>> > > very
>> > > > least
>> > > > 3-4 months), so we are ok to take it slowly, follow the right process,
>> > > and
>> > > > then
>> > > > even contribute back and make them more ready - if that would be a good
>> > > > start,
>> > > > We are happy to do so. We could eventually also add an "ASF conference
>> > > > template"
>> >

Re: Simple question: Project blogs

[Jarek Potiuk]

One comment - some projects might have their own "blogs"
https://airflow.apache.org/blog/ , Yes, not being the best citizen
(sorry!), having our own blog link

But I saw recently,  there have been improvements / changes in the way how
blogs are published, so maybe - if we see some incentives why following
other's - we can migrate.
Not sure how important it is to have all the blogs under the common
"umbrella" - is it important? necessary? recommended?

J.

On Tue, Jul 11, 2023 at 2:29 PM Brian Proffitt  wrote:

> All:
>
> Thank you for the data, it is very helpful. I have my question answered
> now!
>
> BKP
>
>
> On Tue, Jul 11, 2023 at 8:25 AM Ayush Saxena  wrote:
>
> > Hi,
> > A bunch of the old ones can be found here:
> > https://blogsarchive.apache.org/
> >
> > Rest for some projects: .blog.apache.org, like Hive:
> > https://hive.blog.apache.org/ and for some it is
> > .apache.org/blogs like Iceberg:
> > https://iceberg.apache.org/blogs/ and Ranger
> > https://ranger.apache.org/blogs.html
> >
> > Most of the projects would have a link on their main website, so you
> > can explore there.
> >
> > -Ayush
> >
> > On Tue, 11 Jul 2023 at 17:50, Bertrand Delacretaz
> >  wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jul 11, 2023 at 12:13 AM Brian Proffitt 
> wrote:
> > > >
> > > > Simply put, if I want to direct people to Apache project's blogs, I
> > would
> > > > send them to... where?..
> > >
> > > Right now I don't think that we have an answer, we used to have
> > > https://twitter.com/planetapache and http://planet.apache.org/ but not
> > > anymore.
> > >
> > > Maybe https://apache.org/blogs would be a good place, with a manually
> > > curated list of project blogs?
> > >
> > > Or list them at https://projects.apache.org/ adding metadata to the
> > > projects LDAP info
> > >
> > > What would be really useful IMO is an aggregated RSS feed to which our
> > > project blogs can be added, which I suppose planet.a.o was doing.
> > >
> > > -Bertrand (who recently restarted using RSS feeds and super happy about
> > that)
> > >
> > > -
> > > 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: Setting up Git Project under comdev for Community Over Code EU

[Jarek Potiuk]

Yep. That would be perfect.

On Mon, Jul 10, 2023 at 3:29 PM Rich Bowen  wrote:

> We could also put something under the Apachecon ldap group, which I am
> thinking of renaming to conferences or events. That might be a better
> match?
>
> Shosholoza,
> Rich
>
>
> On Sun, Jul 9, 2023, 02:28 Jarek Potiuk  wrote:
>
> > Sure. if we have "apachecon-*" (and possibly renamed). That would be the
> > best approach.
> >
> > No problem with waiting until Rich is back.
> >
> > J.
> >
> >
> > On Sun, Jul 9, 2023 at 7:57 AM Willem Jiang 
> > wrote:
> >
> > > FYI， ApacheCon Asia conference website[1] uses Hugo with a customer
> > > theme[2].
> > >
> > > [1]https://github.com/apache/apachecon-acasia
> > > [2]
> > https://github.com/apache/apachecon-acasia/tree/master/themes/apachecon
> > >
> > >
> > > Willem Jiang
> > >
> > > Twitter: willemjiang
> > > Weibo: 姜宁willem
> > >
> > > On Sat, Jul 8, 2023 at 7:35 PM Jarek Potiuk  wrote:
> > > >
> > > > >
> > > > >
> > > > > > it might be simpler to manage if we used this PMC instead -
> > although
> > > > > > that requires some consensus from this PMC first to own something
> > > that
> > > > > > really belongs to conferences.
> > > > >
> > > >
> > > > Yeah. That's what I am really looking for :).  I would also be fine
> to
> > > > create
> > > > a new group ? PMC? for that if ComDev is not the right place. Maybe
> > there
> > > > are ways to set up other "entities" for the ASF structure that could
> > > serve
> > > > the purpose ? I do not (yet) know all the options - but I believe PMC
> > is
> > > not
> > > > the only option to have a separate "LDAP group".
> > > >
> > > > > One note: do you *specifically* want to copy the ComDev site repo?
> > Or
> > > > > > do you want to start with the infra-supported (but simpler
> design)
> > > >
> > > >
> > > > Not really. We can start from scratch, I was referring more to the
> > > > integrations
> > > > that we get from INFRA: .asf.yaml, emails sent to specific discussion
> > > lists
> > > > we
> > > > can customize - generally following best practices there.
> > > >
> > > >
> > > > >
> > > > My experience with both Hugo and Pelican is that Hugo is easier to
> > > > > customise.
> > > > >
> > > >
> > > > Yes we also prefer Hugo. Airflow Summit Website - prepared entirely
> by
> > > the
> > > > Software
> > > > Guru team - our producers - is based on Hugo, so that would be our
> > > > preference as well.
> > > >
> > > > https://github.com/softwareguru/airflowsummit-website
> > > >
> > > >
> > > > >
> > > > > > template repo they recommend for new projects?
> > > > > >https://github.com/apache/template-site
> > > > >
> > > > > I don't think that is production ready.
> > > > >
> > > >
> > > > We have quite a lot of time before our website will be public (at the
> > > very
> > > > least
> > > > 3-4 months), so we are ok to take it slowly, follow the right
> process,
> > > and
> > > > then
> > > > even contribute back and make them more ready - if that would be a
> good
> > > > start,
> > > > We are happy to do so. We could eventually also add an "ASF
> conference
> > > > template"
> > > > for others and possibly pave the way to follow the same "process"
> (but
> > I
> > > am
> > > > usually
> > > > of the opinion that in order to make something reusable, you have to
> > make
> > > > it usable
> > > > first - so that would likely be a next step and we could "lead by
> > > > example").
> > > >
> > > >
> > > > > >
> > > > > > No.  AFAIK any direct write access to /apache repos can only come
> > > from
> > > > > > ASF committers who have signed an ICLA.  But that's solvable for
> a

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

[Jarek Potiuk]

Sure. if we have "apachecon-*" (and possibly renamed). That would be the
best approach.

No problem with waiting until Rich is back.

J.


On Sun, Jul 9, 2023 at 7:57 AM Willem Jiang  wrote:

> FYI， ApacheCon Asia conference website[1] uses Hugo with a customer
> theme[2].
>
> [1]https://github.com/apache/apachecon-acasia
> [2]https://github.com/apache/apachecon-acasia/tree/master/themes/apachecon
>
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Jul 8, 2023 at 7:35 PM Jarek Potiuk  wrote:
> >
> > >
> > >
> > > > it might be simpler to manage if we used this PMC instead - although
> > > > that requires some consensus from this PMC first to own something
> that
> > > > really belongs to conferences.
> > >
> >
> > Yeah. That's what I am really looking for :).  I would also be fine to
> > create
> > a new group ? PMC? for that if ComDev is not the right place. Maybe there
> > are ways to set up other "entities" for the ASF structure that could
> serve
> > the purpose ? I do not (yet) know all the options - but I believe PMC is
> not
> > the only option to have a separate "LDAP group".
> >
> > > One note: do you *specifically* want to copy the ComDev site repo?  Or
> > > > do you want to start with the infra-supported (but simpler design)
> >
> >
> > Not really. We can start from scratch, I was referring more to the
> > integrations
> > that we get from INFRA: .asf.yaml, emails sent to specific discussion
> lists
> > we
> > can customize - generally following best practices there.
> >
> >
> > >
> > My experience with both Hugo and Pelican is that Hugo is easier to
> > > customise.
> > >
> >
> > Yes we also prefer Hugo. Airflow Summit Website - prepared entirely by
> the
> > Software
> > Guru team - our producers - is based on Hugo, so that would be our
> > preference as well.
> >
> > https://github.com/softwareguru/airflowsummit-website
> >
> >
> > >
> > > > template repo they recommend for new projects?
> > > >https://github.com/apache/template-site
> > >
> > > I don't think that is production ready.
> > >
> >
> > We have quite a lot of time before our website will be public (at the
> very
> > least
> > 3-4 months), so we are ok to take it slowly, follow the right process,
> and
> > then
> > even contribute back and make them more ready - if that would be a good
> > start,
> > We are happy to do so. We could eventually also add an "ASF conference
> > template"
> > for others and possibly pave the way to follow the same "process" (but I
> am
> > usually
> > of the opinion that in order to make something reusable, you have to make
> > it usable
> > first - so that would likely be a next step and we could "lead by
> > example").
> >
> >
> > > >
> > > > No.  AFAIK any direct write access to /apache repos can only come
> from
> > > > ASF committers who have signed an ICLA.  But that's solvable for a
> > > > special case like this, by having an officer or PMC simply agree to
> > > > invite those outside individuals at Software Guru to be committers
> here.
> > > >   Note also that individuals can be made committers, not companies.
> > >
> > >
> > I believe signing ICLA by those individuals from Software Guru is not a
> > problem at all,
> > and they will be perfectly happy to act in their "individual" capacity. I
> > know them personally
> > very well and I am sure this is not a problem. And on a personal (about
> > individuals) note -
> > they are so much personally involved with other Apache conferences
> > (Airflow, Beam)
> > and now running the Community Over Code EU, that it would make absolutely
> > sense to make them committers.
> >
> > I think it's more of a question - if they are made committers in ComDev,
> > they will have
> > access to the main ASF community site, so possibly having a separate
> > "group"? makes
> > more sense.
> >
> > So I think the main question I have now - is it really possible to have
> it
> > in comdev?
> >
> > Or should we (any leads on how?) create a new "group" to manage it.
> >
> > J.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

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

[Jarek Potiuk]

Sounds like a great plan. Thanks Shane.

On Sat, Jul 8, 2023 at 3:03 PM Shane Curcuru  wrote:

> To simplify (and then answer) the question:
>
> - You & EU organizers need a repo for the COCEU website, which will
> include some new contributors, and might be used for other events later.
>
> - Is there consensus with the ComDev PMC to be the organizational owner
> for your new repo?  The INFRA issue is that every repo needs a VP or PMC
> to own it, so we know who's providing direct oversight.
>
> My consensus is yes, go create one.  ComDev already has the events.a.o
> website repo, so as long as Jarek and the other COCEU organizers will be
> coming here to actively manage the new repo, that seems fine.
>
>https://github.com/apache/comdev-events-site
>
> I would give it a few days to see if anyone objects, then ask Infra to
> create the repo here, and once done, send a new email to dev@ with the
> brief plan for what the work is going to be, and alerting people you're
> going to propose some new committer votes.
>
> --
> - 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
>
>

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

[Jarek Potiuk]

>
>
> > it might be simpler to manage if we used this PMC instead - although
> > that requires some consensus from this PMC first to own something that
> > really belongs to conferences.
>

Yeah. That's what I am really looking for :).  I would also be fine to
create
a new group ? PMC? for that if ComDev is not the right place. Maybe there
are ways to set up other "entities" for the ASF structure that could serve
the purpose ? I do not (yet) know all the options - but I believe PMC is not
the only option to have a separate "LDAP group".

> One note: do you *specifically* want to copy the ComDev site repo?  Or
> > do you want to start with the infra-supported (but simpler design)


Not really. We can start from scratch, I was referring more to the
integrations
that we get from INFRA: .asf.yaml, emails sent to specific discussion lists
we
can customize - generally following best practices there.


>
My experience with both Hugo and Pelican is that Hugo is easier to
> customise.
>

Yes we also prefer Hugo. Airflow Summit Website - prepared entirely by the
Software
Guru team - our producers - is based on Hugo, so that would be our
preference as well.

https://github.com/softwareguru/airflowsummit-website


>
> > template repo they recommend for new projects?
> >https://github.com/apache/template-site
>
> I don't think that is production ready.
>

We have quite a lot of time before our website will be public (at the very
least
3-4 months), so we are ok to take it slowly, follow the right process, and
then
even contribute back and make them more ready - if that would be a good
start,
We are happy to do so. We could eventually also add an "ASF conference
template"
for others and possibly pave the way to follow the same "process" (but I am
usually
of the opinion that in order to make something reusable, you have to make
it usable
first - so that would likely be a next step and we could "lead by
example").


> >
> > No.  AFAIK any direct write access to /apache repos can only come from
> > ASF committers who have signed an ICLA.  But that's solvable for a
> > special case like this, by having an officer or PMC simply agree to
> > invite those outside individuals at Software Guru to be committers here.
> >   Note also that individuals can be made committers, not companies.
>
>
I believe signing ICLA by those individuals from Software Guru is not a
problem at all,
and they will be perfectly happy to act in their "individual" capacity. I
know them personally
very well and I am sure this is not a problem. And on a personal (about
individuals) note -
they are so much personally involved with other Apache conferences
(Airflow, Beam)
and now running the Community Over Code EU, that it would make absolutely
sense to make them committers.

I think it's more of a question - if they are made committers in ComDev,
they will have
access to the main ASF community site, so possibly having a separate
"group"? makes
more sense.

So I think the main question I have now - is it really possible to have it
in comdev?

Or should we (any leads on how?) create a new "group" to manage it.

J.

Setting up Git Project under comdev for Community Over Code EU

[Jarek Potiuk]

Dear ComDev friends,

I need some help in determining how we should approach developing the
Community Over Code EU website and I believe dev@community.a.o is the right
place to ask for it.

We are getting up to speed with preparation of the Community Over Code EU
2024 in Bratislava (June 3-6) and as a person leading a Tech committee of
the conference, I am looking for a place where we could host our website.

The conclusion of the discussion we had last week was that we want to get a
statically generated website - based on the same tooling and ASF
integration tooling as https://github.com/apache/comdev-site is. We will
eventually make it available at eu.communityovercode.org and (secondary)
goal of that is to make it a nice starting point for future other
communityovercode sites (NA one is currently run via wordpress). Some of
the committee members are particularly keen on transparency and
archiving/inclusivity, so rather than creating a repo outside of ASF (which
is an option) we thought the best will be to get a repo in the "apache"
organisation.

>From the JIRA ticket https://issues.apache.org/jira/browse/INFRA-24741 - if
we were to use INFRA supported GitHub repos (under the apache/
organisation) we need a "project" to host it and Rich suggested that
instead of creating a new one we could do it via comdev.

We have some specific requirement re: access to the repository. We are not
a typical PMC where we have committers and PMC members. We are cooperating
with a producer company (Software Guru) and rather than merging their PRs
we would rather (especially at the crucial times before the event) want to
give them direct "push" access and capability of merging PRs.

So my question is:

* has something like that been done before?
* is this possible for comdev projects to have such repos
(apache/comdev-commovercode-eu) with external people access ?
* or maybe we need to add those who need write access to comdev? Is this
possible (how about accessing other comdev projects ?).
* how do we get such a repository (I cannot create a new repo with
self-serve, I guess I would need to become a comdev member?)
* or maybe it's not a good idea for whatever reasons and we should create
some specific initiative (I understand comdev is not a PMC, so having
communityovercodeeu group might not be the worst idea).

Looking forward to getting some clarity on those questions :)

J.

Re: Changing the defaults for GitHub generated email titles?

[Jarek Potiuk]

Big +1 on that one.

There were cases in the past that some "breaking" changes in GitHub
integration were introduced already for various reasons.
Given some warnings and explanations why we are doing it (basically to
better fulfill our mission) it's a change that is pretty easily
actionable for the PMCs and individuals who subscribe to those messages
(Mostly it's reconfiguring bots and mailing filtering rules that one
would set up to filter the messages).

It's a change, for sure, and people will complain (this is a given and
expected), but overall I think the example with StreamPipes really shows
the reason why it's worth doing it.

I think one way to make it simple for the PMCs to accept such a change is
to have an explanation and simple instruction on how to go back to the
previous settings. Then the answer to complaints might be "Adapt your
bots/rules (best) or follow  to bring back the old
setting".

BTW. I also agree having longer than single-letter [TOPICS] and always
prepend it with [GH] would be a more reasonable default.

J.

On Fri, Jun 30, 2023 at 10:36 AM sebb  wrote:

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

Re: Community-run MVP programs at the ASF

[Jarek Potiuk]

Good point Daniel. I like this perspective.

On Thu, Jun 22, 2023 at 1:33 PM Daniel Gruno  wrote:

> On 2023-06-21 19:55, Melissa Logan wrote:
> > Hello CommDev people:
> >
> > Is there precedent at ASF for a community-run MVP program? If not, would
> > anyone like to collaborate on this to help provide guidance to ASF
> > projects? And is CommDev the right place?
> >
> > In a recent Cassandra Marketing Working Group meeting (1) we discussed
> the
> > idea of a community-hosted MVP program that adheres to ASF governance.
> MVP
> > programs reward people who are actively contributing to/promoting a
> project
> > by designating them as "MVPs" and listing them on community channels
> (e.g.
> > project website). It's a great way to get people onboarded/involved,
> > recruit committers, and grow awareness for a project. This would also
> > create more opportunities for non-code contributions to a project.
> >
> > MVP would be a non-governing body (2); one would need to re-apply or be
> > nominated annually.
> >
> > Each PMC would have to approve of the MVP program and be part of the MVP
> > Committee to select MVPs each year. For the first year, the committee
> > would include at least one PMC member, 3-5 active contributors that will
> be
> > selected by the PMC member(s), and a program lead. In subsequent years,
> the
> > committee would include PMC member(s), previous MVPs, and a program lead.
> >
> > Doc below (3); feedback would be much appreciated. If you can't access
> it,
> > let me know and I'll find another way to share. Thank you!
> >
> > (1)
> https://cwiki.apache.org/confluence/display/CASSANDRA/2023-06-07+Meeting
> > (2) https://www-paulau.staged.apache.org/foundation/governance/
> > (3)
> >
> https://docs.google.com/document/d/19sExbQFMBvEJPjE_YaZNZAp54I14Ez0sooybqm800qA/edit#
> >
>
> I have no problem with badges/milestones or other "egalitarian"
> approaches to recognize merits, and I do believe there has been some
> talks in comdev earlier about some sort of universal badge system for
> committers as a fun (emphasis on fun!) community challenge.
>
> I do however strongly dislike the term "MVP", I find it in the same
> category as "rock star developer" or "10x engineer". Not alone does it
> very clearly favor those that work professionally on a project as part
> of their dayjob (as opposed to the hobbyists that essentially founded
> this foundation), it is also quite often extremely myopic. How does one
> define an MVP? Most commits/PRs? or is it most work done relative to the
> time allotted? absolute effort or effort relative to skill set? How does
> development stack up against envangelism?
>
> While you can form a group to work out the process, the end result, the
> "MVP" title will always be misleading unless you have tens of footnotes
> explaining what it really means.
>
> My two cents would be to stick to a simpler, less opinionated
> recognition system if a project really must have one. Have the badge or
> achievement title strictly refer to the achievement criteria - nothing
> less, nothing more.
>
>
>
> -
> 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?

[Jarek Potiuk]

I think it's really a matter of project's choice.

Those who use gitflow use main(master)/release/develop - they have
all well-defined meaning and it's cool for projects using it. For other
projects, main might be the default development choice if their
merge/release workflow is simpler (that's airflow's choice for example -
even if it is a code repo, this works well for us too). I personally adapt
to whatever style project uses and don't prefer one over the other -
whatever is comfortable for most of the people contributing there is cool.
This is what I love about git that it does not make opinionated choices and
every project can choose their workflow.

J

On Sun, Apr 2, 2023 at 7:20 PM Gary Gregory  wrote:

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

Re: FOSS Backstage 2023

[Jarek Potiuk]

Cool. Will be great to have dinner Sharan :).

If anyone else wants to join I can make a reservation for the dinner -
https://www.google.com/maps/place/Restaurant+La+Miro is one that is
rather close to TUECHTIG (and happens to be next to my hotel :) so I
took the liberty to choose it).

I can make a reservation.

J.

On Fri, Mar 10, 2023 at 3:01 PM Sharan F  wrote:
>
> Hi Jarek
>
> I land at 6.30pm on Sunday so should be available (and hungry!) around
> 8pm..so count me in.
>
> Thanks
> Sharan
>
>
> On Fri, 10 Mar 2023, 13:37 Jarek Potiuk,  wrote:
>
> > I am going to be in Berlin on Sunday ~ 6pm ... Anyone up for dinner ~ 8pm ?
> >
> > J.
> >
> > On Tue, Feb 28, 2023 at 1:19 PM Nasser Kaze  wrote:
> > >
> > > I will be there too. It will be my first time. Looking forward to
> > meeting you all.
> > >
> > > Regards
> > > Nasser
> > > 
> > > From: Paul Berschick 
> > > Sent: Tuesday, February 28, 2023 11:13:03 AM
> > > To: dev@community.apache.org 
> > > Subject: Re: FOSS Backstage 2023
> > >
> > > Hi everyone,
> > >
> > > Glad to hear you are interested in joining us! If you plan to do so and
> > > do not have a ticket yet, I'd recommend to get one now, as we are nearly
> > > sold out.
> > >
> > > Of course there is always the option to take part in the online event:
> > > https://23.foss-backstage.de/online-experience/
> > >
> > > Looking forward to meeting many of you in Berlin soon!
> > > Paul
> > >
> > > Am 28.02.23 um 11:03 schrieb Sharan F:
> > > > Hi
> > > >
> > > > It's been a while but I plan to be at FOSS Backstage too. :-)
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > >
> > > > On Tue, 28 Feb 2023, 10:47 Claude Warren,  wrote:
> > > >
> > > >> I will be there.  I am giving a talk: "The Cathedral, the Bazaar, and
> > the
> > > >> Coffeehouse"
> > > >>
> > > >>
> > > >> On Mon, Feb 27, 2023 at 6:51 PM Jarek Potiuk 
> > wrote:
> > > >>
> > > >>> Hello.
> > > >>>
> > > >>> Anyone else is planning to be at FOSS Backstage in Berlin?
> > > >>>
> > > >>> Quoting last year's message from Paul:
> > > >>>
> > > >>> FOSSBack is a Berlin-based conference on all non-technical issues in
> > > >>> the Free and Open
> > > >>> Source Software world: Community management, legal/compliance,
> > project
> > > >>> leadership, collaboration, adopting Open Source in corporations, etc.
> > > >>>
> > > >>> The conference also offers free tickets for people of
> > underrepresented
> > > >>> groups. More
> > > >>> info on that: https://foss-backstage.de/diversity/
> > > >>>
> > > >>> You can find more information and the full schedule here:
> > > >>> https://23.foss-backstage.de/schedule/
> > > >>>
> > > >>> The Conference is on 13 & 14 March.
> > > >>>
> > > >>> BTW. Paul if you are listening - are there any discount vouchers for
> > > >>> the Apache Members like last year :P ?
> > > >>>
> > > >>> J.
> > > >>>
> > > >>> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > >>> For additional commands, e-mail: dev-h...@community.apache.org
> > > >>>
> > > >>>
> > > >> --
> > > >> LinkedIn: http://www.linkedin.com/in/claudewarren
> > > >>
> > >
> > >
> > > -
> > > 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: FOSS Backstage 2023

[Jarek Potiuk]

I am going to be in Berlin on Sunday ~ 6pm ... Anyone up for dinner ~ 8pm ?

J.

On Tue, Feb 28, 2023 at 1:19 PM Nasser Kaze  wrote:
>
> I will be there too. It will be my first time. Looking forward to meeting you 
> all.
>
> Regards
> Nasser
> 
> From: Paul Berschick 
> Sent: Tuesday, February 28, 2023 11:13:03 AM
> To: dev@community.apache.org 
> Subject: Re: FOSS Backstage 2023
>
> Hi everyone,
>
> Glad to hear you are interested in joining us! If you plan to do so and
> do not have a ticket yet, I'd recommend to get one now, as we are nearly
> sold out.
>
> Of course there is always the option to take part in the online event:
> https://23.foss-backstage.de/online-experience/
>
> Looking forward to meeting many of you in Berlin soon!
> Paul
>
> Am 28.02.23 um 11:03 schrieb Sharan F:
> > Hi
> >
> > It's been a while but I plan to be at FOSS Backstage too. :-)
> >
> > Thanks
> > Sharan
> >
> >
> > On Tue, 28 Feb 2023, 10:47 Claude Warren,  wrote:
> >
> >> I will be there.  I am giving a talk: "The Cathedral, the Bazaar, and the
> >> Coffeehouse"
> >>
> >>
> >> On Mon, Feb 27, 2023 at 6:51 PM Jarek Potiuk  wrote:
> >>
> >>> Hello.
> >>>
> >>> Anyone else is planning to be at FOSS Backstage in Berlin?
> >>>
> >>> Quoting last year's message from Paul:
> >>>
> >>> FOSSBack is a Berlin-based conference on all non-technical issues in
> >>> the Free and Open
> >>> Source Software world: Community management, legal/compliance, project
> >>> leadership, collaboration, adopting Open Source in corporations, etc.
> >>>
> >>> The conference also offers free tickets for people of underrepresented
> >>> groups. More
> >>> info on that: https://foss-backstage.de/diversity/
> >>>
> >>> You can find more information and the full schedule here:
> >>> https://23.foss-backstage.de/schedule/
> >>>
> >>> The Conference is on 13 & 14 March.
> >>>
> >>> BTW. Paul if you are listening - are there any discount vouchers for
> >>> the Apache Members like last year :P ?
> >>>
> >>> J.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>>
> >> --
> >> LinkedIn: http://www.linkedin.com/in/claudewarren
> >>
>
>
> -
> 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

FOSS Backstage 2023

[Jarek Potiuk]

Hello.

Anyone else is planning to be at FOSS Backstage in Berlin?

Quoting last year's message from Paul:

FOSSBack is a Berlin-based conference on all non-technical issues in
the Free and Open
Source Software world: Community management, legal/compliance, project
leadership, collaboration, adopting Open Source in corporations, etc.

The conference also offers free tickets for people of underrepresented
groups. More
info on that: https://foss-backstage.de/diversity/

You can find more information and the full schedule here:
https://23.foss-backstage.de/schedule/

The Conference is on 13 & 14 March.

BTW. Paul if you are listening - are there any discount vouchers for
the Apache Members like last year :P ?

J.

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

Re: Idea: build a New Contributor Guide Tool

[Jarek Potiuk]

Yep. That's what those chatbots can do now.  And what's even more
interesting, the answers it gives are getting deeper and deeper (and
more accurate) as long as you ask more refined questions.
There are of course risks involved, but I am equally impressive how
good and legible answers the bots provide, and I am sure in the (near)
future when chat-bot war from Open AI, Google and others inevitably
gets into full-blown competition, I am sure we will be able to make
the bots focused on the material we already have even better.

On Wed, Feb 8, 2023 at 8:37 PM Ayush Saxena  wrote:
>
> That sounds so cool and magical Craig
> OpenAi seems pretty smart, Impressive!!!
>
> Makes sense to me to do some improvemenrs there (If my opinion counts), that 
> might be very helpfull may not be very much immediately but for sure in the 
> near future.
>
> -Ayush
>
> >
> > On 09-Feb-2023, at 12:50 AM, Craig Russell  wrote:
> >
> > As an experiment, I logged into chat.openai.com and asked it to tell me 
> > how to contribute code to Apache. [1] Then I asked why the ICLA is needed. 
> > [2]
> >
> > These AI are smarter than we might think,
> >
> > I expect that refining the questions and editing the replies might be 
> > easier than creating the content by hand.
> >
> > WDYAT?
> >
> > Craig
> >
> > [1]I asked:
> >
> > how do i contribute code to The Apache Software Foundation?
> >
> > They replied:
> >
> > To contribute code to the Apache Software Foundation (ASF), you need to 
> > follow these steps:
> >
> > Choose a project: Browse the list of Apache projects and find one that 
> > aligns with your area of expertise.
> >
> > Get involved: Participate in the project's community by asking questions, 
> > contributing documentation, and providing feedback.
> >
> > Set up your development environment: Follow the project's guidelines for 
> > setting up your development environment.
> >
> > Sign and submit an ICLA: The Apache Software Foundation requires 
> > contributors to sign a Contributor License Agreement (CLA). This document 
> > outlines your rights and obligations as a contributor to the ASF.
> >
> > Create a patch or feature branch: Develop your changes in a separate branch 
> > and submit a patch or feature request to the project's mailing list or 
> > issue tracker.
> >
> > Follow the project's coding standards: Ensure that your code follows the 
> > project's coding standards and style guide.
> >
> > Engage in code review: Be prepared to engage in a code review process with 
> > other project contributors.
> >
> > Merge your changes: Once your changes have been reviewed and approved, they 
> > will be merged into the project's main codebase.
> >
> > Note: The specifics of the contribution process may vary from project to 
> > project, so be sure to consult the project's guidelines for more 
> > information.
> >
> > [2] why is an ICLA needed for Apache?
> >
> > The Apache Software Foundation requires contributors to sign a Contributor 
> > License Agreement (CLA) in order to ensure that the code contributed to its 
> > projects can be distributed under the terms of the Apache License. The 
> > Apache License is a permissive open-source license that allows for the use, 
> > modification, and distribution of software, but requires that the original 
> > copyright notices and license terms are preserved.
> >
> > The ICLA is a legal agreement between the contributor and the ASF that 
> > clarifies the rights and responsibilities of both parties. By signing the 
> > ICLA, the contributor grants the ASF a perpetual, non-exclusive, no-charge, 
> > worldwide license to use, copy, modify, distribute, and sublicense the 
> > contribution, and agrees to hold the ASF harmless from any claims related 
> > to the contribution.
> >
> > The ICLA helps the ASF to maintain a clear chain of custody for the code in 
> > its projects, and protects the integrity of the Apache brand by ensuring 
> > that all contributions are made in accordance with the ASF's legal and 
> > ethical standards.
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> 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: Idea: build a New Contributor Guide Tool

[Jarek Potiuk]

I had some interesting discussions about it at FOSDEM and similar
topics popped up - how to make first-time/new contributor onboarding
more engaging and welcoming and helped, but at the same time not to
over-burden ourselves with mostly repetitive questions/answers.

And I would love to carry this conversation here as well.

I looked at the proposal and with the CYOA engines, one of the
problems is that you have to script it and investi in defining the
paths/branches, but with the recent development in the AI tools (hello
Chat-GPT) - maybe we do not have to do it.
Ut might be controversial, but I think one option that we **might**
consider (and I am very cautiously dropping it here - without strongly
supporting it - just as an idea) to use some AI engine/chatbot to
help.

I believe we just passed the level where answers from such chatbots
are much more useful and correct (and legible) than even several
months ago. They are mostly correct, there is a lot of "caution"
introduced by those who develop the engines to avoid a number of
pitfalls from the past. And I imagine, if you feed such a bot with
previous conversations of ours (hey they are all public!) both the
range of questions/answers and useful answers such bot could "serve"
might be way, way better and wider (and might be reinforced
conrinuously with real "new" conversations) than anything we could
ever do with scripting. For me this might be really like every "human"
answer we have is automatically building a new path and adventure in
such CYOA engine.

Of course - that shoudl be clear that the bot is not human answering
(this was at least the conclusion of FOSDEM discussions I had). We
(humans) have to watch the conversations to correct problems if the
answer is wrong and probably a multitude of other things.

And there are risks of dehumanising such conversations, so we should
likely carefully make sure that there is human-in-the-loop at the
moments where it is really needed.

And maybe somehow we could combine the two - CYOA engine with some
basic adventure openers + ChatBot. I am pretty sure the CYOA engine
developers - see the writing on the wall, and the AI models will be -
hopefully - more and more open and easier (and cheaper) to use, so
maybe simply CYOA engine choice that you dicsuss in the docs Shane,
shoudl be chosen based on current/future ChatBot/AI integration.

No concrete proposal yet, I am just wondering if this is a topic that
people have strong opinions about :).

J.


On Tue, Feb 7, 2023 at 11:51 PM Shane Curcuru  wrote:
>
> I've been burnt out for a while at trying to answer newcomer's
> questions.  It's not scalable, and even when I do the work to not answer
>   a question - but instead send a link to the doc where the answer is -
> it's still tedious.
>
> So I finally thought: why don't we try to automate some part of this?
>
> https://cwiki.apache.org/confluence/display/COMDEV/New+Contributor+Guidance+Tool
>
> There are a million things we could do to make newcomers more welcome
> and feel confident they can find a place they might fit.  This is just
> one, but it's one I'm hoping other folks are interested in helping to build.
>
> Feel free to discuss here; and please join in on the wiki to crystalize
> what thing we might actually build that would help guide a complete
> newcomer to someplace they might find interesting.  Besides being a
> really cool tool, it'd save Maxim a lot of time!
>
> --
> - 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
>

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

Re: FOSDEM 2023 Update

[Jarek Potiuk]

re
> also near to one the entry / exit doors. Our position meant that people
> had to pass by us to get in or out - so we got a lot of foot traffic.
> The FOSDEM team grouped foundations linked to Community Advocacy
> together so we were alongside OpenUK, FOSSASIA, Software Freedom
> Conservancy. FSFE, FOSSASIA, Ecliipse Foundation etc.
>
> On Saturday I arrived with the bag of swag to find a few people ready
> and waiting to help out with setup. We quickly put up the banner (it
> definitely needed two people!), blew up some balloons and got the booth
> table covered in stickers (So much so that during the event people came
> to take photos of our display). We kept telling people that this was
> only a small selection of ASF projects. Even so - we did have requests
> for stickers we didn't have (so they are on my list for next time). Also
> we ran out of the HTTP Server stickers (everyone wanted a sticker of the
> first ASF project). We ran out of stickers for Apache Maven, Apache
> Kafka this time.
>
> As well as stickers we gave away some balloons for the children (and
> some adults too), cleaning cloths for glasses and screens, mugs, head
> tubes, pens, small cable bags, key rings and mask extenders (as there
> were a few people with masks). The cleaning cloths were very popular -
> everyone wearing glasses seemed to want one.
>
> For the things that we had limited supply of - we told people that to
> get one would cost 'a good conversation' :-) So we had some really good
> conversations - about projects, technology and I think even open source
> software for space technology! This is one of the reasons that having a
> booth presence is so good for outreach and general community building.
>
> People also came to talk to us about other open source events that were
> being organised that they hoped we or our communities might be
> interested in participating in. One of these was the Open System Days
> Croation Linux Users Conference who have a CFP open
> https://www.dorscluc.org/call-for-speakers/. We also offered a free
> meeting room for community meetups for any developers based in and
> around Portugal.
>
> We had people from different projects spend some time on the booth - so
> special shoutout and huge thanks to Claude Warren, Matthew de
> Detrich, Arnout Engelen, Myrle Krantz, Jarek Potiuk, Gilles Sadowski,
> Johan Corveleyn, Jean-Frederic Clere, Herve Boutemy for helping out on
> the booth. Thanks also to everyone that dropped by to say Hi and chat
> -it was all fun.
>
> There were rumours of 1 attending people but nothing concrete.
> Usually FOSDEM attracts over 8000 developers. Whatever the number there
> seemed to be an endless stream of people, there were lots of people at
> the foodcarts, on the first and second floors, walking to and from the
> other buildings and going in and out of the talks.  I understand that
> many of the talks have been recorded so if you didn't make it then you
> will still get a chance to see it. If you have never experienced FOSDEM
> then I would encourage you to keep it on your radar and see if you can
> make it to the next one.
>
> Once again I would like to sincerely thank everyone that was involved in
> helping out to make our participation at FOSDEM a success. Am already
> looking forward to doing it all again next year if we get the chance.
>
> Please feel free to respond with any of your FOSDEM experiences,
> feedback, thoughts or general comments!
>
> 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

Re: FOSDEM 2023

[Jarek Potiuk]

Ah. Better late than never (I completely missed the page).

On Thu, Feb 2, 2023 at 9:08 PM Sharan F  wrote:
>
> Hi Arnout
>
> Thanks for volunteering to help with booth setup.
>
> Booth setup starts at around 8.30am on Saturday morning and we need to have
> everything setup by 10am. At the end of the day we need to close and leave
> by around 5.30pm.
>
> Our booth is located in K building and we have position 11. I am planning
> to get there between 8.30am and 9am.
>
> I am bringing a table cloth and banner with the ASF logos. Those don't take
> too long to setup. I also have hundreds of stickers and some swag that we
> need to put out and ration throughout the day.
>
> Yes it would be good to have a few more people sign up for time on the
> booth as it can get really tiring and everyone needs a break after a couple
> of hours.
>
> Hopefully see you over the weekend.
>
> Thanks
> Sharan
>
> On Thu, 2 Feb 2023, 20:39 Arnout Engelen,  wrote:
>
> > On Wed, Jan 11, 2023 at 6:15 PM Sharan Foga  wrote:
> > > It looks like our stand is going to be on the ground floor this year.
> > >
> > > https://fosdem.org/2023/stands/
> > >
> > > We have been asked to ensure that there is someone at the booth at all
> > times - from memory the tables generally have enough space for two people
> > comfortably (with chairs) and three if standing.
> > >
> > > https://cwiki.apache.org/confluence/display/COMDEV/FOSDEM+2023
> >
> > I signed up to help with booth setup if needed - when does that
> > happen? Friday evening or Saturday morning?
> >
> > Also I'm sure we'd like some more people to sign up to take booth
> > shifts - I'm looking forward to meeting y'all there :).
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> > > On 2023/01/11 17:05:32 Sharan Foga wrote:
> > > > That's great news.
> > > >
> > > > Everyone is welcome - I suspect this year it will be like a reunion
> > (everyone glad to get together again!)
> > > >
> > > > Thanks
> > > > Sharan
> > > >
> > > > On 2023/01/08 08:55:45 Geertjan Wielenga wrote:
> > > > > I’ll be there, happy to help on Saturday, on Sunday I’ll be here,
> > anyone
> > > > > involved in OpenJDK based languages/technologies (Java, Kotlin) is
> > more
> > > > > than welcome:
> > > > >
> > > > > https://fosdem.org/2023/schedule/track/friends_of_openjdk/
> > > > >
> > > > >
> > > > > Gj
> > > > >
> > > > > On Sun, 8 Jan 2023 at 09:53, Myrle Krantz  wrote:
> > > > >
> > > > > > Hey all, I'll be there for FOSDEM as well.  Part of my time will
> > be with my
> > > > > > employer, but I'd be happy to help man the ASF stand on Saturday
> > afternoon
> > > > > > or Sunday morning.  Let me know how I can help.
> > > > > >
> > > > > > Best Regards,
> > > > > > Myrle
> > > > > >
> > > > > > On Sun, Dec 11, 2022 at 9:53 PM Dirk-Willem van Gulik <
> > > > > > di...@webweaving.org>
> > > > > > wrote:
> > > > > >
> > > > > > > On 11 Dec 2022, at 21:13, Sharan Foga  wrote:
> > > > > > > > On 2022/12/11 17:51:02 Dirk-Willem van Gulik wrote:
> > > > > > > >> On 11 Dec 2022, at 16:33, Sharan Foga 
> > wrote:
> > > > > > > >>
> > > > > > > >>> Some good news! I just saw that we have been given an ASF
> > booth for
> > > > > > > FOSDEM so looking forward to being there on 4th and 5th February
> > and
> > > > > > > meeting up with everyone.
> > > > > > > >>
> > > > > > > >> Good news indeed !
> > > > > > > >>
> > > > > > > >>> As usual I will setup a wiki page with the details and
> > people can
> > > > > > book
> > > > > > > booth time to promote their project.
> > > > > > > >>
> > > > > > > >> Excellent.
> > > > > > > >>
> > > > > > > >> Just a thought - can we think of some clever logistics by
> > which we get
> > > > > > > every apache committer some sort of recognisable thing ? E.g.
> > like those
> > > > > > > small feather lapel-pins. And do so very early (and perhaps fill
> > some
> > > > > > holes
> > > > > > > in the booth duty roster in the process) ?
> > > > > > > >
> > > > > > > > We did have some 'Committer' and 'Member' pins made so let me
> > take a
> > > > > > > look through my swag inventory to see if we have any left.
> > > > > > >
> > > > > > > Something quite generic - like just the feather - is fine too;
> > in many
> > > > > > > ways it does not matter much what you are :) —my thinking was
> > just to
> > > > > > show
> > > > > > > presence and to encourage conversations. Make use of this rare
> > social
> > > > > > event.
> > > > > > >
> > > > > > > Dw
> > > > > > >
> > -
> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > > >
> > >
> > > 

Re: How to start contributing to Apache Organisation

[Jarek Potiuk]

I think you should watch the GSoC announcements for that.

You might not realise how distributed the ASF is and how it works Tanmoy,
Priya. This is not a regular "corporate" structure - each project is
completely independent and each PMC applies to various programs completely
on their own discretion.

The timeline to apply for participation for organisations ends at end of
February: https://developers.google.com/open-source/gsoc/timeline - and
which of the projects from the ASF apply is completely unknown at this
stage (and since each of the projects will apply individually - the only
good source of the information which project participate will be known and
published by the GSoC.

J.


On Tue, Dec 27, 2022 at 7:06 AM Tanmoy Sarkar  wrote:

> Yes, that will be really helpful to start.
> ᐧ
>
> On Tue, Dec 27, 2022 at 11:19 AM Priya Sharma  >
> wrote:
>
> > Hello Gilles,
> > Can you also share where we can find the list of Apache projects
> > participating in GSoC 2023?
> >
> > On Tue, 27 Dec 2022 at 06:07, Gilles Sadowski 
> > wrote:
> > >
> > > Hi.
> > >
> > > Le lun. 26 déc. 2022 à 22:37, SUSHRITH B  a
> > écrit :
> > > >
> > > > Hello,
> > > >
> > > > I am Sushrith Bogi, pursuing engineering in Information Technology,
> 2nd
> > > > year. I want to contribute in GSoC 2023 in Apache organisation.I am
> > aware
> > > > of C, C++, Python, Java, HTML and CSS.I don't know where to start and
> > what
> > > > new technologies and languages to learn to make it to GSoC
> 2023,please
> > help
> > > > me.I am a very quick learner and hardworking,I hope you will be
> > replying.
> > >
> > > There are many, many, projects at the ASF.
> > > Where to start primarily depends on what you are interested in.
> > > If you are asking what language to learn, I guess that Java is a
> > > safe choice.
> > > A good way to increase your proficiency is probably to read the
> > > code of projects to which you might want to apply, and start to
> > > contribute as soon as possible.
> > >
> > > Regards,
> > > Gilles
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> >
> > --
> > Best Regards,
> > Priya
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

Re: Enquiry regarding projects as a potential contributor

[Jarek Potiuk]

You should find the right project for you and ask there. We are not having
insights in specific projects in "general" here. Apache Software Foundation
has many projects and each of them is managed independently from each other
- you need to reach out individually to each project that you find that
matches your skill set and you might want to pick interest in.


J.


On Thu, Dec 8, 2022 at 4:36 PM Manaswini Simhadri Kavali <
manaswin...@outlook.com> wrote:

> Greetings,
>
> I am Manaswini Simhadri Kavali, from Bengaluru, India. I am currently
> pursuing
> My undergraduate studies in Computer Science and Engineering, and am
> currently in my first year.
> I was looking through the 2022 GSoC organization list, and came across
> yours and would love to contribute, and potentially work with you.
>
> I have some experience working with C++ for about 2 years, and basic
> knowledge about C and HTML. I am also pretty new to open source as a
> concept in general, and I am interested in learning and exploring more. I
> would love to know if there is something open for me to work with, at the
> moment or connect with people which would help me learn more.
> I am also looking forward to participate in GSoC 2023, so this would act
> as great experience before the actual project.
> Thank you.
>
>
> Regards,
> Manaswini Simhadri Kavali.
>
>
>

Re: Compatibility with RHEL8.6

[Jarek Potiuk]

You should check it for each project independently. Each project in Apache
is run independently from each other, and you should check it
individually for each project. Ideally - find it in the docs, then you can
ask at the devlist of each project (you should find the devlist information
in each of the projects you mentioned) and you can ask there (or in
whatever communication media each project has).

J.

On Fri, Dec 9, 2022 at 8:08 AM Prince Sonu (EXT)
 wrote:

> Hello Team
> Can you Please let me know that
> Apache Felix Web Management Console version 3.8.1
> Geronimo JTA 1.1 Spec Apache version-1.1.1
> HTTPComponents HttpClient, Apache version-4.0.1
> HTTPComponents HttpCore, Apache version-4.0.1
> WS Common Utilities Apache version-1.0.2
>
> is Compatibility with RHEL8.6 or not, if no then Please tell me which
> version Support RHEL 8.6.
>
>
> Thanks
> Prince Kr Sonu
>
>

Re: [DISCUSS] Proposal of guidelines for individuals <> businesses Apache Way compliant relationships

[Jarek Potiuk]

And in case you cannot see the attachment because of mailing list
policies - feel free to reach me out directly - I will send you a copy
by whatever means is convenient for you.

On Sun, Dec 4, 2022 at 9:43 PM Jarek Potiuk  wrote:
>
> And following up on another (infra thread) - feel free NOT to click on
> the link in the message if you are not willing to transmit anything to
> Google.
>
> I am attaching a PDF version of the proposal for those who prefer not to.
>
> On Sun, Dec 4, 2022 at 9:40 PM Jarek Potiuk  wrote:
> >
> > Hello everyone,
> >
> > I would like to start a discussion on something I've been thinking and
> > discussing with a number of people offline, before I brought it here
> > for wider discussion.
> >
> > I want to (eventually) propose to the board of the ASF to publish
> > (formally among other ASF guidelines) a document that would make it
> > clearer to both businesses and individuals what kind of business
> > relations are "good" and "comply" with the Apache Way.
> >
> > The document is short, and follows - I think - the spirit of other
> > guidelines and policies that the ASF publishes - in terms of being
> > succinct, helpful and informative, but presenting the "spirit" of the
> > guidelines rather than "precise implementation" of it.
> >
> > More context about the need is in the document - and I would really
> > love people to take a close look at "whys" in the documentation. I
> > opened the document for comments - so feel free to comment there if
> > you have some concrete small proposals, but I think for the wider
> > audience we should make "general" comments here in the comm devlist.
> >
> > https://docs.google.com/document/d/1vp0eOeAHhRuTtps5I602MPduW7hYxtPORkkDtnlrIFo/edit
> >
> > Some more comments  - more personal - why do I personally think we need it?
> >
> > I think sustainability and longevity of the Foundation and the PMCs it
> > shepherds should be of uttermost importance. And I think in order to
> > achieve that, we need more individuals at different stages of their
> > professional career.- younger, more experienced, seasoned to be able
> > to make the contribution to Apache Projects independently from their
> > Employer funding, an important factor in the sustainability and
> > longevity - strengthening vendor neutrality and other Apache Way
> > approach.
> >
> > I am an example of an individual who established relationships with 5
> > different businesses for my OSS contributions, and thanks to that I
> > can "make a living" from being an open-source contributor. I even get
> > enough "living" that I can afford to spend (exclusively) my own money
> > to go (as I did last week) to be a panelist and represent Open-Source
> > practitioners at the EU commission in Brussels at the workshops
> > https://swforum.eu/sustainability, together with Roman, Dirk and
> > Geertjan (and maybe there were others I am not aware of).
> >
> > For me the workshops were very interesting, not only because we were
> > able to pass a message to those who later will be participating in
> > creating the laws and regulations, but also because I found that there
> > are also others who have the same struggles I want to address in the
> > document. Among other, undoubtedly important topics, I felt there were
> > many voices on how individuals are struggling with establishing
> > relations with businesses that are stakeholders in the open software
> > they contribute to - procurement, contracts, expectations were all
> > present in the voices I've heard. I could be biased of course, and
> > hear only what I wanted to hear stronger than other voices, but still
> > I think I've heard enough of the very same topics I raised in the
> > document.
> >
> > But coming back to why I think it is needed?
> >
> > I had pretty unique experience, drive and capabilities (and quite a
> > persistence) to get where I got now with being full-time open-source
> > contributor. But it was far from easy. I got a number of bits and
> > pieces together from various conversations and documents in order to
> > be able to negotiate proper contracts, know what I can expect and also
> > I had to convince the business partners of mine (yes - partners as I
> > treat them and they treat me) that what I want in the contracts (and
> > needs to be present due to the nature of cooperation and ASF
> > expectations) is OK for them. I WISH I had such a document handy when
> > I was negotiating my contract with Som

Re: [DISCUSS] Proposal of guidelines for individuals <> businesses Apache Way compliant relationships

[Jarek Potiuk]

And following up on another (infra thread) - feel free NOT to click on
the link in the message if you are not willing to transmit anything to
Google.

I am attaching a PDF version of the proposal for those who prefer not to.

On Sun, Dec 4, 2022 at 9:40 PM Jarek Potiuk  wrote:
>
> Hello everyone,
>
> I would like to start a discussion on something I've been thinking and
> discussing with a number of people offline, before I brought it here
> for wider discussion.
>
> I want to (eventually) propose to the board of the ASF to publish
> (formally among other ASF guidelines) a document that would make it
> clearer to both businesses and individuals what kind of business
> relations are "good" and "comply" with the Apache Way.
>
> The document is short, and follows - I think - the spirit of other
> guidelines and policies that the ASF publishes - in terms of being
> succinct, helpful and informative, but presenting the "spirit" of the
> guidelines rather than "precise implementation" of it.
>
> More context about the need is in the document - and I would really
> love people to take a close look at "whys" in the documentation. I
> opened the document for comments - so feel free to comment there if
> you have some concrete small proposals, but I think for the wider
> audience we should make "general" comments here in the comm devlist.
>
> https://docs.google.com/document/d/1vp0eOeAHhRuTtps5I602MPduW7hYxtPORkkDtnlrIFo/edit
>
> Some more comments  - more personal - why do I personally think we need it?
>
> I think sustainability and longevity of the Foundation and the PMCs it
> shepherds should be of uttermost importance. And I think in order to
> achieve that, we need more individuals at different stages of their
> professional career.- younger, more experienced, seasoned to be able
> to make the contribution to Apache Projects independently from their
> Employer funding, an important factor in the sustainability and
> longevity - strengthening vendor neutrality and other Apache Way
> approach.
>
> I am an example of an individual who established relationships with 5
> different businesses for my OSS contributions, and thanks to that I
> can "make a living" from being an open-source contributor. I even get
> enough "living" that I can afford to spend (exclusively) my own money
> to go (as I did last week) to be a panelist and represent Open-Source
> practitioners at the EU commission in Brussels at the workshops
> https://swforum.eu/sustainability, together with Roman, Dirk and
> Geertjan (and maybe there were others I am not aware of).
>
> For me the workshops were very interesting, not only because we were
> able to pass a message to those who later will be participating in
> creating the laws and regulations, but also because I found that there
> are also others who have the same struggles I want to address in the
> document. Among other, undoubtedly important topics, I felt there were
> many voices on how individuals are struggling with establishing
> relations with businesses that are stakeholders in the open software
> they contribute to - procurement, contracts, expectations were all
> present in the voices I've heard. I could be biased of course, and
> hear only what I wanted to hear stronger than other voices, but still
> I think I've heard enough of the very same topics I raised in the
> document.
>
> But coming back to why I think it is needed?
>
> I had pretty unique experience, drive and capabilities (and quite a
> persistence) to get where I got now with being full-time open-source
> contributor. But it was far from easy. I got a number of bits and
> pieces together from various conversations and documents in order to
> be able to negotiate proper contracts, know what I can expect and also
> I had to convince the business partners of mine (yes - partners as I
> treat them and they treat me) that what I want in the contracts (and
> needs to be present due to the nature of cooperation and ASF
> expectations) is OK for them. I WISH I had such a document handy when
> I was negotiating my contract with Some companies (8 months was the
> longest). That would have cut many discussions and off-tracks - mostly
> because both parties would know for sure that the expectations of OSS
> contributions are different and that they are very different from the
> "standard" service contracts.
>
> I think not many of the people who would like to be full-time
> contributors will have enough financial stability, persistence,
> experience in contract negotiations and sometimes just the stamina and
> be bold enough to go through that without any guidelines and help. A
> good example was whe

[DISCUSS] Proposal of guidelines for individuals <> businesses Apache Way compliant relationships

[Jarek Potiuk]

Hello everyone,

I would like to start a discussion on something I've been thinking and
discussing with a number of people offline, before I brought it here
for wider discussion.

I want to (eventually) propose to the board of the ASF to publish
(formally among other ASF guidelines) a document that would make it
clearer to both businesses and individuals what kind of business
relations are "good" and "comply" with the Apache Way.

The document is short, and follows - I think - the spirit of other
guidelines and policies that the ASF publishes - in terms of being
succinct, helpful and informative, but presenting the "spirit" of the
guidelines rather than "precise implementation" of it.

More context about the need is in the document - and I would really
love people to take a close look at "whys" in the documentation. I
opened the document for comments - so feel free to comment there if
you have some concrete small proposals, but I think for the wider
audience we should make "general" comments here in the comm devlist.

https://docs.google.com/document/d/1vp0eOeAHhRuTtps5I602MPduW7hYxtPORkkDtnlrIFo/edit

Some more comments  - more personal - why do I personally think we need it?

I think sustainability and longevity of the Foundation and the PMCs it
shepherds should be of uttermost importance. And I think in order to
achieve that, we need more individuals at different stages of their
professional career.- younger, more experienced, seasoned to be able
to make the contribution to Apache Projects independently from their
Employer funding, an important factor in the sustainability and
longevity - strengthening vendor neutrality and other Apache Way
approach.

I am an example of an individual who established relationships with 5
different businesses for my OSS contributions, and thanks to that I
can "make a living" from being an open-source contributor. I even get
enough "living" that I can afford to spend (exclusively) my own money
to go (as I did last week) to be a panelist and represent Open-Source
practitioners at the EU commission in Brussels at the workshops
https://swforum.eu/sustainability, together with Roman, Dirk and
Geertjan (and maybe there were others I am not aware of).

For me the workshops were very interesting, not only because we were
able to pass a message to those who later will be participating in
creating the laws and regulations, but also because I found that there
are also others who have the same struggles I want to address in the
document. Among other, undoubtedly important topics, I felt there were
many voices on how individuals are struggling with establishing
relations with businesses that are stakeholders in the open software
they contribute to - procurement, contracts, expectations were all
present in the voices I've heard. I could be biased of course, and
hear only what I wanted to hear stronger than other voices, but still
I think I've heard enough of the very same topics I raised in the
document.

But coming back to why I think it is needed?

I had pretty unique experience, drive and capabilities (and quite a
persistence) to get where I got now with being full-time open-source
contributor. But it was far from easy. I got a number of bits and
pieces together from various conversations and documents in order to
be able to negotiate proper contracts, know what I can expect and also
I had to convince the business partners of mine (yes - partners as I
treat them and they treat me) that what I want in the contracts (and
needs to be present due to the nature of cooperation and ASF
expectations) is OK for them. I WISH I had such a document handy when
I was negotiating my contract with Some companies (8 months was the
longest). That would have cut many discussions and off-tracks - mostly
because both parties would know for sure that the expectations of OSS
contributions are different and that they are very different from the
"standard" service contracts.

I think not many of the people who would like to be full-time
contributors will have enough financial stability, persistence,
experience in contract negotiations and sometimes just the stamina and
be bold enough to go through that without any guidelines and help. A
good example was when I was not aware that I should really publicly
state that my contributions will continue regardless if I am paid or
not - I only learned that from a comment in one of the discussions
with "longtimers" on one of the devlists.

And I think just raising awareness to both - individual and businesses
that such cooperation is not only possible but also perfectly OK with
the ASF as long as it follows certain guidelines

I also think (and I have some discussions that confirm that) that
having such guidelines published by the ASF, would enable 3rd party
companies to start providing services that would make it even easier:
payments, contract negotiations and signing, legal responsibilities,
lead generation - having such guidelines in place would remove the
need 

Re: European Commission Workshop day on Open-Source Sustainability

[Jarek Potiuk]

Good for me. I **might** be late 15 minutes (but I will try to finish
my earlier call a bit before to be on time.

On Tue, Nov 29, 2022 at 7:40 PM Dirk-Willem van Gulik
 wrote:
>
> Folks,
>
> Several of us are now either on panels or going to this event (at least 4 in 
> 3 panels; or petty much every panel if I take the 'Friends of Apache' a bit 
> more liberal).
>
> I understood from Roman that, while he will be there, the ASF will not have 
> any formal position at this event - or a specific message they want to get 
> across. But I've not managed to prepare something with him in an apache 
> contrext.
>
> So would it make sense if those that go to have a short chat tomorrow 
> evening, 1900 CET time in a general 'friends of open source and apache' sort 
> of way ? Just to make sure that we more or less prioritise what we think is 
> important / not create noice that dillutes something we all agree on.
>
> I've created:
>
> https://meet.jit.si/moderated/6a0e28986b76ede1082453b5db022b71a6e1de734c93d138e79b5ab3c08f410a
>
> to prepare a bit. I've gathered what I read on
>
> https://docs.google.com/document/d/1JuPPcktiLpr9ei3r9n0JDhP2UTW7s5suLt_XAtmAeQU/edit?usp=sharing
>
> And would be nice to know who is there (happy to add you to a participants 
> signal with limited life-time/auto-delete chat if you DM me a number).
>
> With kind regards,
>
> Dw
>
>
>
> EU-Workshop -- Informal prep Chat for Friends of Open Source and Apache
> Scheduled: 30 Nov 2022 at 18:45 to 19:45, CET
> Location: 
> https://meet.jit.si/moderated/6a0e28986b76ede1082453b5db022b71a6e1de734c93d138e79b5ab3c08f410a
>

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

Re: [DISCUSS] ASF Mastodon instance?

[Jarek Potiuk]

We have yesterday applied to https://hub.fosstodon.org/ for an account
in Apache Airflow. And I encourage others who are interested to make
their own choice and do the same for their PMC.

My personal opinion is that such a discussion makes very little sense
if the goal is "let's get a centrally managed solution first" before
we even know if that makes sense and where our users are and how the
situation evolves.

Mastodon makes it relatively painless to migrate between servers if
needs be - 
https://blog.joinmastodon.org/2019/06/how-to-migrate-from-one-server-to-another/
- this the whole point of federation approach, if you do not like the
moderation and COC you get at one server, you move and you bring your
users with you (if they concur).

IMHO It's far better if each of the individuals who are interested to
run Mastodon, will do it on behalf of their PMC, just try it and apply
at the server of their choice.

Let's gather experiences and see what works. If we find that we need
an Apache run server and have good rationale behind it, we might
decide to do it (or not).

And I think it's far too early (if even at all) to expect INFRA to do
anything about it on the central level or get a server that one of the
ASF members will run for all the PMCs.

On a philosophical level - I personally believe trying to centralise
the approach is also pretty much 100% against the whole idea of
federation. The federation is not there to "centralise" the approach,
but to make it easier to distribute it and the ASF is VERY well
prepared for that distributed world. The PMC independence and
self-governance except very, very few central services and really
important aspects (like licensing. release policy and publishing) is
precisely what federation idea supports. And federation means that at
the PMC level you have both the benefit of choosing the server as well
as the responsibility to make the choice and bear the cost of setting
up/managing and moderating. It looks like centralization is an attempt
to reap the benefits of decentralisation without bearing the cost of
managing it.

Somehow it does not click to try to centralize it back.

J.

On Tue, Nov 8, 2022 at 2:30 AM Peter Hunsberger
 wrote:
>
> On Mon, Nov 7, 2022 at 1:28 PM Gary Gregory  wrote:
>
> > Then why not just keep using Slack?
> >
> > Mastodon would let you federate to the rest of the outside world.  It
> could let the ASF tell the world that some group of people (coming from the
> Apache Mastodon server) have been vetted by us. Vetted could range
> somewhere from "has an apache.org email" to approved by the board
> somehow  (We could do both with two different servers.)
>
> Peter Hunsberger
>
>
> > Gary
> >
> > On Mon, Nov 7, 2022, 14:17 Niels Basjes  wrote:
> >
> > > Yes, normally it is a lot of work for moderating. Hence my proposal to
> > > limit it to (initially) only projects (pmc).
> > >
> > > By doing that I thought to eliminate the need for additional moderation.
> > >
> > > Niels
> > >
> > > On Mon, 7 Nov 2022, 18:00 Peter Kovacs,  wrote:
> > >
> > > > Hi Niels
> > > >
> > > > Am 07.11.22 um 12:58 schrieb Niels Basjes:
> > > > > I'm sorry to admit I don't have the skills to keep something like
> > this
> > > > > running reliable at this scale.
> > > >
> > > > I think you speak tech skills. I guess we would need moderators, and
> > > > mentors for projects.
> > > >
> > > > Social media / Mastodon is not only about tech. It is about community,
> > > > isn't it?
> > > >
> > > > >
> > > > > Niels
> > > > >
> > > > > On Mon, 7 Nov 2022, 12:41 Peter kovacs, 
> > > wrote:
> > > > >
> > > > >> Hi all
> > > > >>
> > > > >> @walter
> > > > >> I don't think your argument is a good one.
> > > > >> If the name is inappropriate then we should change the Domain and
> > not
> > > > try
> > > > >> to stay invisible.
> > > > >> However this should be a different discussion.
> > > > >>
> > > > >> @Niels
> > > > >> An own server means work. I think it is only feasible if we get a
> > team
> > > > >> together that maintains the service. Would you volunteer in case one
> > > is
> > > > >> build?
> > > > >>
> > > > >> All the best
> > > > >> Peter
> > > > >>
> > > > >>
> > > > >> Am 6. November 2022 23:52:03 MEZ schrieb Walter Cameron <
> > > > >> walter.li...@waltercameron.com>:
> > > > >>> Hi Niels,
> > > > >>>
> > > > >>> I don’t think it’s appropriate to further expand the impact of our
> > > > >>> improperly
> > > > >>> owned domain. Why risk people on social media confusing us with an
> > > > >>> Apache organization?
> > > > >>>
> > > > >>> Gunalchéesh,
> > > > >>> Walter
> > > > >>>
> > > > >>> On Sun, Nov 6, 2022 at 12:20 PM Niels Basjes 
> > > wrote:
> > > > >>>
> > > >  Hi,
> > > > 
> > > >  Given the recent events around twitter I had this crazy idea:
> > > >  What if the ASF would run their own Mastodon instance under the
> > > > >> apache.org
> > > >  domain?
> > > > 
> > > >  Primarily this would make it possible for all projects 

Re: Tidelift

[Jarek Potiuk]

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

[Jarek Potiuk]

I am also scheduled for the "Workshop 3.4 Exploring practical solutions to
ensure long term sustainability of open source software".

Geertjan - agree on both - beer a day before and a zoom call to prepare -
likely with Molly/Joe involved to get their help on messaging, and view.
Related to what DW wrote - yep. We should always speak as individuals, but
I think we can be better prepared and not caught by "press" if we got some
kind of briefing from Molly/Joe. I have no experience speaking at EU
forums, but I remember when I was speaking at a big banking conference when
I was in a small Mobile Payment startup, I appreciated a lot all the
briefing, help and suggestions from the people with PR/Marketing experience
and I think that was one of the best prepared talks of mine.
(I actually quit the startup soon after because I realized at that very
conference that what our CEO was selling us internally was a complete
dreampipe, but that's a completely different story :D).

Best time for me is Tuesday, Thursday or Friday next week - anything
before  3pm CET should work.

J.



On Fri, Nov 4, 2022 at 7:50 PM Geertjan Wielenga
 wrote:

> I’m scheduled for the panel on open source and the public sector.
>
> Maybe everyone from Apache who will be involved in one way or another
> should do a Zoom call just to chat about it all, see where the overlaps and
> cross-panel strategies are, and have drinks before/after the event itself
> in Brussels, I’d be very keen for both.
>
> Gj
>
> On Fri, 4 Nov 2022 at 10:58, Joe Brockmeier  wrote:
>
> > On Fri, Oct 28, 2022 at 11:42 AM Dirk-Willem van Gulik
> >  wrote:
> > >
> > > On 28 Oct 2022, at 17:27, Jarek Potiuk  wrote:
> > >
> > > > Absolutely - that is great to have such support.
> > > >
> > > > I was a bit afraid that my points might be much more "private" than
> > > > the "ASF" voice in general so having the opportunity to get comms
> > > > involvement for such a potentially "wavy" event is cool.
> > >
> > > Well - regardless - unless we manage to create something like a
> position
> > paper & get board approval -- any interaction at this level will always
> be
> > on a personal basis.
> > >
> > > And even then - it is just that paper that represents the view of the
> > ASF; not a person.
> > >
> > > I.e. one cannot speak on behalf of the ASF; only talk about what you
> > personally think would work well according to your view on the apache
> > community.
> >
> > Agreed that these interactions are not "official" and I'd hope anybody
> > participating would be careful to mention their statements, etc. are
> > as individuals who are members/contributors (whatever is appropriate)
> > and not official statements on behalf of the foundation. (Unless there
> > is one.)
> >
> > That said... the more we can speak with one voice and prep folks, the
> > better.
> >
> >
> >
> > --
> > Joe Brockmeier
> > Vice President Marketing & Publicity
> > j...@apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

Re: Tidelift

[Jarek Potiuk]

Since you wanted to have a smooth and nice cooperation  -  as a
courtesy, Is it possible that you explicitly put ASF there and
obligations that are not valid (especially when you reach out to PMCs
of Airflow projects)?

I think otherwise it puts too much responsibility on individuals to
check what their organisations are ok with. It puts them in a bit of
an awkward position where something is "required" but "not really".

This might also lead to a number of legal questions from those people
(very few people read past legal issues and discussions in JIRA) which
we want to avoid.
Also some people might not realise that their organisations are not
aware of the requirements and they might accidentally break those.

A bit of context here why I am interested and discussing it. It's not
that I am arguing against Tidelift or anything like that. I am just
very transparent and try to get this whole cooperation between
contributors and stakeholders hashed out and defined in simple and
straightforward terms that are beneficial for the Foundation.

The good of ASF, its longevity, values, and vendor-neutrality is an
absolute key for me and top priority.

So I wanted to make sure that what we will come up, will be completely
neutral and that many, many 3rd-parties like tidelift can make use of
it - equally.

Over the last few months I've been thinking, discussing and drafting
with a number of people and organisations (and lawyers of mine) a
missing piece in the puzzle. Likely soon I will make a proposal to
legal/board and comms about having a simple page for
"contributor/stakeholder" relationships, where the ASF will actually
explicitly provide some DOs/DOnts and looser guidelines for such a
cooperation (the above will be one of DON'T). When/If it happens - we
will propose and discuss it here, at legal-discuss and finally if that
succeeds - it might be presented to the board.

Would that help if you have such a page and explicitly refer to it in
case of ASF and you could refer to it explicitly ?

J.


On Mon, Oct 31, 2022 at 10:41 PM Ralph Goers  wrote:
>
> The wording now basically says that anything listed as an obligation can
> be ignored if it conflicts with your organization’s policy requirements. So
> that should make it possible for individuals to agree to work with Tidelift
> without the PMC agreeing to anything.
>
> That said, 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. But it is not a requirement on a project to do either of these 
> things.
>
> Ralph
>
>
>
> > On Oct 31, 2022, at 1:47 PM, Jarek Potiuk  wrote:
> >
> > I think the door was always open to work with Tidelift by the individuals.
> > This has never been a problem (and recruiting individual PMC members
> > by you was never a problem either).
> >
> > However, yes, I do have a question now. I am actually - as a PMC
> > member of Apache Airflow interested. You have one of your customers
> > here, actually :).
> >
> > The statement in your document is a bit vague and seems to workaround
> > the original problem a bit.
> >
> > 1) Are you going to ask the individuals in your contract to put the
> > logo of Tidelift on the project's website / github project etc. (in
> > what form) ?
> > 2) Or will you ask them so that they personally as individuals mention
> > they are sponsored by Tidelift ?
> >
> > The former is still not good for ASF IMHO (nothing changed), the
> > latter has always been good (nothing changed either).
> >
> > So for me it looks like nothing has changed, you just stopped
> > requiring individuals to mention Tidelift in the PMC docs (this was
> > the original problem)?
> >
> > Is my understanding correct?
> >
> > Let's take Apache Airflow. What would be a requirement if you want to
> > work with me?
> >
> > And yes - I am perfectly fine to discuss it in public - transparency
> > is super important to me and I always disclose what is the scope and
> > requirements of cooperation I do on open-source (I think this is
> > crucial in the OSS contracts).
> >
> > J.
> >
> > On Mon, Oct 31, 2022 at 7:42 PM Joshua Simmons
> >  wrote:
> >>
> >> Hi Jarek,
> >>
> >>> I have a question - what exactly do you expect here? What is your ask and
> >>> proposal ? I read the docs and I have not found any action that I or
> >> anyone
> >>> else here could take here - (possibly that's why you did not get any
> >>> response) - I looked at it several days ago but I could not find anything
> 

Re: Tidelift

[Jarek Potiuk]

I think the door was always open to work with Tidelift by the individuals.
This has never been a problem (and recruiting individual PMC members
by you was never a problem either).

However, yes, I do have a question now. I am actually - as a PMC
member of Apache Airflow interested. You have one of your customers
here, actually :).

The statement in your document is a bit vague and seems to workaround
the original problem a bit.

1) Are you going to ask the individuals in your contract to put the
logo of Tidelift on the project's website / github project etc. (in
what form) ?
2) Or will you ask them so that they personally as individuals mention
they are sponsored by Tidelift ?

The former is still not good for ASF IMHO (nothing changed), the
latter has always been good (nothing changed either).

So for me it looks like nothing has changed, you just stopped
requiring individuals to mention Tidelift in the PMC docs (this was
the original problem)?

Is my understanding correct?

Let's take Apache Airflow. What would be a requirement if you want to
work with me?

And yes - I am perfectly fine to discuss it in public - transparency
is super important to me and I always disclose what is the scope and
requirements of cooperation I do on open-source (I think this is
crucial in the OSS contracts).

J.

On Mon, Oct 31, 2022 at 7:42 PM Joshua Simmons
 wrote:
>
> Hi Jarek,
>
> > I have a question - what exactly do you expect here? What is your ask and
> > proposal ? I read the docs and I have not found any action that I or
> anyone
> > else here could take here - (possibly that's why you did not get any
> > response) - I looked at it several days ago but I could not find anything
> I
> > could do for one. Now, the message popped up in my reminder and I see I
> was
> > not the only one.
>
> Oh, thank you for asking the question. I could have been more clear!
>
> No action requested or response expected, I sent this follow up as a
> courtesy to the community since it generated so much conversation across
> multiple mailing lists (including this one) back in the January-March time
> frame :o)
>
> That being said, any project committers or PMC members who want to explore
> working with Tidelift to underwrite their work: the door is now open! Our
> subscribers use over 1000 org.apache namespace packages, which means income
> is available for every one of those. Folks who are interested should
> discuss with fellow PMC members and are welcome to reach out to me.
>
> I'll be proactively reaching out to some PMCs, but I want to be respectful
> and not gum up this mailing list with recruitment efforts.
>
> If folks have questions or concerns, I'm here to help!
>
> Cheers,
> Josh
>
> Josh Simmons (he/they), Sr. Principal Foundations Advocate @ Tidelift
> <https://tidelift.com/>
> @joshsimmons <https://twitter.com/joshsimmons> | @josh:josh.tel
> <https://josh.tel/@josh> | bluesomewhere on IRC
> TZ: US/Pacific; UTC-07:00 Mar-Nov; UTC-08:00 Nov-Mar
> ad astra per aspera 
>
>
> On Sun, Oct 30, 2022 at 5:50 PM Jarek Potiuk  wrote:
>
> > I have a question - what exactly do you expect here? What is your ask and
> > proposal ? I read the docs and I have not found any action that I or anyone
> > else here could take here - (possibly that's why you did not get any
> > response) - I looked at it several days ago but I could not find anything I
> > could do for one. Now, the message popped up in my reminder and I see I was
> > not the only one.
> >
> > J.
> >
> > On Thu, Oct 20, 2022 at 8:06 PM Joshua Simmons <
> > joshua.simm...@tidelift.com>
> > wrote:
> >
> > > Hi folks, I wanted to follow up on this thread to let everyone know that
> > > we've taken the feedback from ASF community members across a variety of
> > > threads and updated our agreements accordingly. For context, I've
> > attached
> > > a doc summarizing discussion as it stood back in February (including
> > links
> > > to other relevant threads and docs).
> > >
> > > The blocker that was identified was Tidelift's "public notice
> > requirement"
> > > which in most projects would've required an action by the project as a
> > > whole, counter to the (rightful) prohibition of directed development
> > within
> > > ASF-hosted projects.
> > >
> > > To fix that, we added language to all of our agreements that makes it
> > > clear: Tidelift will never ask maintainers to act in contravention with
> > the
> > > policies of their fiscal sponsor.
> > >
> > >
> > > *> If your Project is formally part of a larger open source or

Re: FOSDEM 2023

[Jarek Potiuk]

Same here.

On Tue, Oct 18, 2022 at 1:53 PM jean-frederic clere  wrote:
>
> On 10/16/22 16:36, sharanf wrote:
> > Hi All
> >
> > In case you haven't heard yet. FOSDEM 2023  is
> > back as an in person event. Millions of developers (ok perhaps
> > thousands!) will converge on Brussels to enjoy this mega meetup.
> >
> > We usually try to have an ASF booth at the event. The call for stands is
> > open so I'll put in a submission for a stand for the ASF and see how it
> > goes. We should find out by 1st December if we get a stand or not.
> >
> > Thanks
> > Sharan
> >
> >
>
> I am planning to be there too.
>
> --
> Cheers
>
> Jean-Frederic
>
>
> -
> 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

[Jarek Potiuk]

I have a question - what exactly do you expect here? What is your ask and
proposal ? I read the docs and I have not found any action that I or anyone
else here could take here - (possibly that's why you did not get any
response) - I looked at it several days ago but I could not find anything I
could do for one. Now, the message popped up in my reminder and I see I was
not the only one.

J.

On Thu, Oct 20, 2022 at 8:06 PM Joshua Simmons 
wrote:

> Hi folks, I wanted to follow up on this thread to let everyone know that
> we've taken the feedback from ASF community members across a variety of
> threads and updated our agreements accordingly. For context, I've attached
> a doc summarizing discussion as it stood back in February (including links
> to other relevant threads and docs).
>
> The blocker that was identified was Tidelift's "public notice requirement"
> which in most projects would've required an action by the project as a
> whole, counter to the (rightful) prohibition of directed development within
> ASF-hosted projects.
>
> To fix that, we added language to all of our agreements that makes it
> clear: Tidelift will never ask maintainers to act in contravention with the
> policies of their fiscal sponsor.
>
>
> *> If your Project is formally part of a larger open source organization,
> such a fiscal sponsor or other non-profit that provides technical
> infrastructure to open source projects, Tidelift will not require you to
> perform Services that are in conflict with any written requirements of that
> organization.*
>
> The full text of our updated agreement can be found here:
> https://support.tidelift.com/hc/en-us/articles/4406309657876-Lifter-agreement
>
> Our hope is that this removes a barrier between maintainers of ASF-hosted
> projects and receiving income from downstream users through Tidelift to
> support work which might otherwise go uncompensated.
>
> If there are any other questions or concerns that folks have, please do
> let me know! My role these days is entirely focused on making sure we're
> addressing the needs of foundations like the Apache Software Foundation and
> its member projects. I've also included co-founder Jeremy Katz on this
> email, as doing right by foundations and the projects they host is a
> priority for all of Tidelift.
>
> Onward and upward,
> Josh
>
> Josh Simmons (he/they), Sr. Principal Foundations Advocate @ Tidelift
> 
> @joshsimmons  |
> joshua.simm...@tidelift.com | bluesomewhere on IRC
> TZ: US/Pacific; UTC-07:00 Mar-Nov; UTC-08:00 Nov-Mar
> ad astra per aspera [image: ]
>
>
> On 2022/01/11 21:49:59 Ralph Goers wrote:
> > Hello all,
> >
> > Recently the Logging Services PMC was approached by Tidelift offering to
> provide monetary support either to the project or individual committers. To
> obtain that sponsorship the project has to agree to the terms at
> https://support.tidelift.com/hc/en-us/articles/4406309657876-Lifter-agreement.
> It appears that Struts has accepted this already.
> >
> > Some PMC members are interested in pursuing this but I am questioning a)
> whether the agreement conflicts with ASF practices and b) whether the legal
> agreement is too ambiguous. Two ASF members commented on the Logging
> Services private list that they had concerns about the agreement.
> >
> > In response to these concerns I created
> https://issues.apache.org/jira/browse/LEGAL-593. The guidance there
> seemed to be that payment to the ASF by Tidelift would not be allowed but
> payment to individuals might be. No guidance on the agreement was provided.
> It was recommended I post here instead.
> >
> > In looking for more clarification from Tidelift about their agreement
> and who could receive payment we received this response:
> >
> > Great follow up question, you are spot on. Each of the
> individuals on the team page could become a lifter and the funds allocated
> for Log4j would be split between them.
> >
> > Additional pieces of information to add nuance:
> >
> > * For someone to _start_ lifting a project with Tidelift, the
> verification process involves us looking to official sources for
> confirmation–such as the team page. After a project is lifted, the
> verification process ultimately hinges on open communication between us and
> whichever lifter has been nominated to be the primary contact (in full view
> of all of the project's lifters so that we know there's shared agreement).
> >
> > * Funds can be split any way you see fit, evenly or otherwise.
> In most cases, we see an even split. In cases where the funds are directed
> back to a foundation, 100% of the funds go to the foundation and the share
> assigned to the lifters is 0%.
> >
> > * This approach has allowed us to decouple any individual
> project's governance from our own processes, and has proven to be effective
> in many different contexts. As we grow, it may well be that our processes
> need 

Re: European Commission Workshop day on Open-Source Sustainability

[Jarek Potiuk]

Absolutely - that is great to have such support.

I was a bit afraid that my points might be much more "private" than
the "ASF" voice in general so having the opportunity to get comms
involvement for such a potentially "wavy" event is cool.

FYI: So far I've got the feedback from organizers that they have a
"LOT" of interest and they are evaluating what makes sense for them.

J.

On Fri, Oct 28, 2022 at 5:07 PM Molly Monroy  wrote:
>
> Hi all - this looks like a great opp and great topic ideas in the
> discussion. As this process progresses, would you mind keeping me and @Joe
> Brockmeier  in the loop on who will be attending and
> corresponding topics? We imagine this is a forum where what's said could
> make its way to the tech media so we'd love to work with you and offer
> messaging help where we can.
>
> (BTW - For those of you I haven't met, I just joined Constantia to support
> the ASF comms and marketing efforts that Joe leads).
>
> Thank you!
> Molly
>
> On Thu, Oct 27, 2022 at 5:58 AM Jarek Potiuk  wrote:
>
> > I cannot agree more with all the points you raised, DW. Those reflect
> > very well my understanding of ASF role and what we can bring to the
> > table and what are the important parts of what we can advocate for.
> >
> > From my side, I would like to bring to the "Practical" workshop (I
> > sent context to organizers to see how they see it as a topic but I
> > will explain it here as well). I have a feeling that this might be the
> > practical side of some of the points raised by DW :)
> >
> > The points that I wanted to raise at the workshop was about some of
> > the aspects of putting in practice what DW described above:
> >
> > 1) making sure that community-driven process is established and some
> > rules of participation are well understood and followed by all
> > involved parties (individual contributors and stakeholders in projects
> > particularly)
> > 2) empowering more individual contributors who are part of the
> > community and making it replicable to have a model where those
> > contributors (and future ones) can remain independent, and can afford
> > spending a lot of (full?) time on being part of the community and can
> > make decent living from that - at the same time providing stronger
> > vendor-neutrality properties
> > 3) ways how 3rd-parties can be involved without taking over the
> > relationships between contributors and stakeholders
> > 4) practical ways to achieve that  - I have some use-cases and
> > relationships already established that might show how this can be
> > possible (based on my example) and proposals what can be done in the
> > future
> >
> > J.
> >
> >
> > On Thu, Oct 27, 2022 at 1:08 PM Dirk-Willem van Gulik
> >  wrote:
> > >
> > > So I think there are a couple of things I'd personally would like to hit
> > / speak to at this event. In part as we have other parts of the industry
> > approaching this much more from a money/company driven (or take your
> > responsibility) perspective. In priority order:
> > >
> > > 1) "Community over Code" and good governance standards
> > >
> > > Software in general, and open source software in particular, is becoming
> > key to civic society - these days you cannot run a country (or even
> > participate in the democratic process on the legislative side ) without it.
> > >
> > > That means that, like all industries that rose to importance, society
> > increasingly needs to rely on & trust "us". Or ensure it can trust us by
> > regulation (in a lot of countries - industrial regulation (as opposed to
> > self regulation, guilds, etc) started to appear when steam-boilers went
> > bang in the middle of populated areas).
> > >
> > > We're simply too important to ignore.
> > >
> > > In apache - we understand a lot of this already very well - and have a
> > culture (community over code) and a set of checks and balances, or
> > governance, (votes for releases, process, security policies) that is
> > conductive to deserving that trust.
> > >
> > > We do not 'sling code onto github' or over a wall and call it `open
> > source'-- but rather insist that there is a community behind it. Or retire
> > it (to the attic) when there is not -- and it would become a risk or
> > liability because of no maintenance, etc.
> > >
> > > =>  so I would like to further this "community over code"
> > notion.
> > >
> > > And emphasise t

Re: European Commission Workshop day on Open-Source Sustainability

[Jarek Potiuk]

=> so. would like to argue for physical places, of sufficient size  
> to build the right human culture, to work, learn and build these critical 
> skills.
>
> and that this is _NOT_ the problem of open source - but the 
> responsibility of society.
>
> This is not something uncommon - we have plenty of industrial areas where 
> countries build & keep strategic and tactical capcity. And in Europe - this 
> is increasingly done pan-european.
>
> 3) "Software matters too much"
>
> Software matters too much for communities and societies -- so I would 
> personally not want to allow  large corporate interest buy themselves control 
> of this.
>
> I am worried about a self amplifying and 'fiscally welcome' pattern; where we 
> blame some industry for a problem in society. And were we then expect 'them' 
> to resolve this; or pay for something as some sort of penance. But in return 
> then effectively allows the existing and richest players get even more 
> control over the playing field.
>
> As opposed to letting society set & enforce their vision of what is right. 
> And either pick up the tab for that - or tax/fine those that do not comply 
> -and- then allow society to choose where to invest that money  in. Rather 
> than let the inmates run the asylum & direct the funding.
>
> Apache is in a vey good position here - we are one of the defacto industry 
> bodies - but unlike most - we are a community of (people) volunteer(ed by 
> their employers dujour) - not a set of companies. In many ways we are more 
> like the IEEE, the IETF, the institute of chartered engineers or a medical 
> society - -than say, the GSMA or the W3C.
>
> And we have a stellar track record when it comes to resisting & neutering 
> such corporate funding / direction attemts.
>
> But the corollary/downside of that is that we're also ill equipped to do the 
> `boring grunt work' that is often needed once things become so key to 
> society. Such as secretariat services, testing, certification, measuring 
> quality & reporting, etc.
>
> => so would like to argue that this is a role for society; and that 
> we need places where our community can meet which those that want this - and 
> where those that want this participate in our community. But without funding 
> `through us' troubling the waters.
>
> Just like we see in many other industries - where some institute simply acts 
> as the coordinator for such information in the public context. And this also 
> addresses interoperability and standards.
>
> With kind regards,
>
> Dw
>
>
>
>
> > On 27 Oct 2022, at 12:25, Jean-Baptiste Onofré  wrote:
> >
> > By the way, I'm pretty interested to participate on these workshops:
> >
> > 1.1 - Open Source Processors for the Cloud Continuum
> > 2.1 - Open Source Software and Cloud Services and Applications: On the
> > way to more interoperable cloud services
> > 3.4 - Exploring practical solutions to ensure long term sustainability
> > of open source software
> >
> > I chatted today with some Eclipse Foundation guys: they plan to be
> > there as well.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> >
> > On Thu, Oct 27, 2022 at 11:38 AM Jarek Potiuk  wrote:
> >>
> >> Yep. Thanks DW :)
> >>
> >> On Thu, Oct 27, 2022 at 10:43 AM Christofer Dutz
> >>  wrote:
> >>>
> >>> 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 an

Re: European Commission Workshop day on Open-Source Sustainability

[Jarek Potiuk]

3.4. I will be writing a (short) proposal on what I would like to
cover and share it here before sending it to them (I got contact from
DW).

1.1 - is a bit vague to me (and I would rather be a more passive
listener as I am not sure if I have anything to come up with)
2.1 - is interesting, but I think it would be great if someone from
cloudstack takes an active part in it. There were some really
interesting talks from Cloudstack  at ApacheCon's last day and I had
nice conversations there - they have a really interesting stakeholder
setup  and in Cloudstack and possibly that would be a great input.
Maybe someone from cloudstack is listening ? Or if not I can reach out
to the speakers I spoke to I think :)

J,



On Thu, Oct 27, 2022 at 12:26 PM Jean-Baptiste Onofré  wrote:
>
> By the way, I'm pretty interested to participate on these workshops:
>
> 1.1 - Open Source Processors for the Cloud Continuum
> 2.1 - Open Source Software and Cloud Services and Applications: On the
> way to more interoperable cloud services
> 3.4 - Exploring practical solutions to ensure long term sustainability
> of open source software
>
> I chatted today with some Eclipse Foundation guys: they plan to be
> there as well.
>
> Thoughts ?
>
> Regards
> JB
>
>
> On Thu, Oct 27, 2022 at 11:38 AM Jarek Potiuk  wrote:
> >
> > Yep. Thanks DW :)
> >
> > On Thu, Oct 27, 2022 at 10:43 AM Christofer Dutz
> >  wrote:
> > >
> > > 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.
&

Re: European Commission Workshop day on Open-Source Sustainability

[Jarek Potiuk]

Yep. Thanks DW :)

On Thu, Oct 27, 2022 at 10:43 AM Christofer Dutz
 wrote:
>
> 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

-
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

[Jarek Potiuk]

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

[Jarek Potiuk]

The subject is very interesting to me personally, I am not sure if I
would be of much help - not much interaction with politicians and not much
experience with it but if I can be of any help I am happy to travel too.

I think I could take part in the panel:

Workshop 3.4 Exploring practical solutions to ensure long term
sustainability of open source software
This is the subject I've been exploring for quite a while, and by December
I might even have some very tangible examples, use cases and concrete
proposals I could discuss about. If that sounds plausible, I'd love to get
in contact with the panel organizer.

J.

On Tue, Oct 25, 2022 at 12:17 PM Dirk-Willem van Gulik
 wrote:

> On 25 Oct 2022, at 11:52, Christofer Dutz 
> wrote:
>
> > 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.
>
> My understanding as well - happy to help here. But think days - not a week
> in terms of registering informal interest.
>
> Dw.
>
>

Re: First contribution campaign collab?

[Jarek Potiuk]

Great idea.

Happy to help with publicising and with reaching out to our contributors. I
can get some good examples from the past and current (we have a
more-or-less constant stream of new contributors at Airflow (in the order
of 10 new contributors a week I think).
Also happy to brainstorm/discuss at ApacheCon - we have a talk with Ismael
"Growing your contributor's base" which is pretty relevant.

We also just started an initiative together with a few people from Apache
Beam (something that I wanted to mention at the talk) that we want to start
measuring the behaviours of contributors, discussions, etc and eventually
turn it into a tool of sorts that will help commiters and PMC members and
encourage/engage new contributors or prospective contributors to our
projects to continue/grow/make their first serious contributions. We could
likely connect those efforts somehow. There is a (rather little) chance we
will have some very early dashboard prototype by the ApacheCon, but I think
all involved people will be at the ApacheCon and maybe we will find time to
talk about it :)?

J.


On Tue, Sep 27, 2022 at 6:47 PM Rich Bowen  wrote:

> This is certainly something that we have talked about over the years,
> but never got around to, so having M providing some steam behind
> this is very welcome.
>
> One of the things that seems important is making sure that projects
> are also engaged - or, more specifically, that we only promote first-
> contrib for projects that are engaged. I say this because we had some
> first contributor stuff around a recent Apachecon, and the target
> project almost rejected the whole lot because it was "pizzas we didn't
> order" and they hadn't been involved in the conversation. We managed
> to get them to review and accept most of the contributions,
> eventually, but it was an awkward situation.
>
> Anyways, count me in for mentoring and whatever, although time may be
> limited.
>
> --Rich
>
> On Tue, 2022-09-27 at 11:23 -0400, Joe Brockmeier wrote:
> > Hi all,
> >
> > We (M) would like to propose a collaboration with ComDev about
> > encouraging new contributions to ASF projects.
> >
> > Melissa Logan and the Constantia team have drafted a set of
> > messaging
> > and plan for the campaign with an objective of reaching 50 or more
> > people to share their first contribution to an ASF project on social
> > media, etc.
> >
> > Much of this activity is happening *anyway* but we'd like to
> > recognize
> > and encourage it. I'd like to do that with ComDev to:
> >
> > 1) Amplify the effort: If folks in ComDev would like to participate
> > in
> > mentoring, boosting the signal on social media, and/or helping with
> > the marketing side of things that would be awesome.
> > 2) Get input: As I said, people are already making their first
> > contributions and we could solicit contributors to speak up - but
> > I'd
> > like to make sure the campaign is aligned with ComDev!
> > 3) Avoid unwelcome surprises! This is an area with a lot of overlap
> > and we didn't want to spring it on folks without notice. Even if
> > nobody in ComDev participates, having awareness and assent is
> > important.
> >
> > Our current messaging draft is in Google Docs -- happy to give
> > access
> > or share out in Hackmd.io or something else. I can just shoot text
> > to
> > the mailing list, of course, but that's often painful when giving
> > feedback on prose.
> >
> > Best,
> >
> > jzb
> >
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Projects interested in student mentoring

[Jarek Potiuk]

My comments "from the trenches". I think 5 hours a week(-ish) is reasonable
but quite a lot if there is no good support and "framework" to cooperate.

I have quite an experience with Outreachy internships (I co-mentrored 5
interns in two rounds) and they have the minimum 5 hours/week involvement
from mentors, but they provide a LOT of support during the internship. You
have very good and tested instructions for both mentors and mentees to
follow (I would say they have an excellent and battle-tested program for
that). They basically hand-hold both - mentees and mentors during the whole
process - including organising chats for the mentees, encouraging them to
do the right things at the right time, also providing really, really good
mentors instructions "This week you should do that, remember about that,
make sure to talk about this etc. etc.". And they send those in the right
time, so you basically (both as mentor and mentee) get the instructions in
your inbox precisely when you need them. They are also available to help to
solve some issues that might happen during the process. Also what helps
enormously is having a co-mentor - for multiple reasons.

This "organisational" support removes a lot of effort from the shoulders of
the mentor, and gives a lot of "self-guidance" for the mentee to follow.
And thanks to that it is doable, But even with that support, the 5 hours a
week is a huge mental effort. I just a few months ago finished the second
round of the mentorship and I need a year break now (same as last time)
even if it was super-rewarding eventually (three of my 5 mentees got a job
in related IT area as result of the internship),

So my thoughts are - if there is good support from the
professor/university, that's doable (but someone has to do that) -
Outreachy blueprints might be invaluable to build such "framework". If the
university/professor is aware that they will need to do it, that's cool, if
not, then this might be quite heavy and difficult for the mentors.

Also one other comment - there is a recent discussion going on in Outreachy
where they are exploring the possibility of paying the mentors, because
they realise that this might be a huge burden. They are running a survey
now about it to gather more insight. And it's a bit different story with
Outreachy because there mentors can spend their free time on "doing good" -
i.e. help underrepresented people in IT. Getting that as part of a
(presumably) paid  - this way or the other - university class, might raise
a question if such time should be paid or not.

I am now in the "recovery" period, so I personally would not be willing to
take part, but if you think my experience with Outreachy can be helpful I
am happy to talk to your friend Stephen and at least explain to him my
experiences :)

J.

On Tue, Sep 20, 2022 at 2:56 PM Rich Bowen  wrote:

> While at Open Source Summit last week in Dublin I talked with someone
> who is teaching classes about open source. One of the aspects of these
> classes is pairing a student with an open source project, so that they
> can learn what's involved in actual hands-on participation in open
> source. (This is someone that I have known for years, and hugely
> respect, FWIW.)
>
> He asked if there were Apache projects, and, specifically, mentors,
> willing to spend 5 hours a week (ish) to work with a student, directed
> by this professor.
>
> We talked about how important it is that we don't set a student, or a
> project, up for failure, by having a student work on the proverbial
> "pizzas nobody ordered", so that when they deliver, their
> contributions will be rejected or ignored. Thus the need for someone
> willing to help them learn how to communicate with a project, and
> deliver something that's actually valuable.
>
> Are any of you aware of projects where there might be these kinds of
> individuals, who I can introduce to my friend Stephen.
>
> (Note: This is all the information that I have, so any deeper
> questions about how the project is actually administered, funded, etc,
> etc, I will not have answers for.)
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: mentor

[Jarek Potiuk]

I think you are absolutely free to do such courses. Apache Software
Foundation is volunteer driven and fully distributed organisation, and I
think one of the sides of it that it does not scale to individually answer
questions for people like yourself - mostly because it does not scale,
because most of the people here are not paid for their contributions and
clearly even if you do not charge for your courses, this is a a
business you run, so it's a bit on you to make the effort to learn.

But this is not a problem and this part is already covered: EVERYTHING
about the ASF is described here https://apache.org/ -> this site has a
wealth of information and you can learn about all the programs, ways of
communication, Apache Way (i.e. what are the values and motivations behind
Apache). I've learned a ton from just reading through the docs - and you
are absolutely welcome and free to do it and see how you can engage.
Generally speaking Apache works on Merit base, and you usually put in some
effort and actually "do" good things and contribute to actually show that
your contributions are valuable rather than talk about them, and learning
how and what you could do is part of the self-reading IMHO. And sharing
such ready courses, and investment you've made into contributing is one of
the best way to show how useful it can be,

But that's not all - we have an apachecon.com in October in New Orleans -
just a month away - and if you register and be present at the conference -
this is absolutely the best way you can get the "all about Apache"
crash-course in 4 days (and you can contribute to the Foundation
financially by buying the ticket). And there - you can meet and talk to
many ASF old-timers and get answers to even bigger numbers of questions you
might have after reading the docs.

I think this is the best course of action for you to take.

J.


On Fri, Sep 2, 2022 at 10:55 AM Abbas Khaleghi  wrote:

> Hello
>
> I am a mentor and I want to contribute to apache programs. Firstly, I need
> someone to guide me completely about apache, then about programs and about
> certain programs. Second, I create free courses, and If I find someone to
> guide me through apache, I'd like to create a course about some programs.
> Third, my courses are all absolutely free. so, let's be in touch and find
> me someone who can respond to my vast amount of questions.
> let's keep the free going and let's be in touch.
> abas khaleqi, aka james wise
> cheers
>

Re: Monthly Member's Moment - August 2022

[Jarek Potiuk]

I think it is about the last time to build the next moment?

Anyone would like to prepare the next one, or are we switching to "vacation
mode" ?

J.


On Fri, Jul 8, 2022 at 1:01 PM Jarek Potiuk  wrote:

> The July newsletter was just sent to members-announce@a.o.
>
> I propose to target to release the next on July 5, 2022 (Friday). I
> think generally Friday is a good time to send it :)
>
> Anyone want to become "chief editor" for August ?
>
> Link for next template is below:
> https://cwiki.apache.org/confluence/x/bB31D
>
> J.
>

Monthly Member's Moment - August 2022

[Jarek Potiuk]

The July newsletter was just sent to members-announce@a.o.

I propose to target to release the next on July 5, 2022 (Friday). I
think generally Friday is a good time to send it :)

Anyone want to become "chief editor" for August ?

Link for next template is below: https://cwiki.apache.org/confluence/x/bB31D

J.

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

Re: Monthly Member's Moment - July 2022

[Jarek Potiuk]

I am just about to t send the moments tomorrow (pinged Infra again to come
back, if not, I will come up with something else) - any comments, feel free
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386250

On Mon, Jun 27, 2022 at 4:07 PM Josh Fischer  wrote:

> It’s really cool you reached out to the Infrastructure team.  Well done,
> Jarek.
>
> On Mon, Jun 27, 2022 at 8:50 AM Jarek Potiuk  wrote:
>
> > I prepared a draft which I tried to make a bit more "personal" :). I
> > have reached out to infra - to get a bit more personal message of what
> > they are doing for the "did you know" section (let's see).
> > I thought a bit and looked at past ones and I agree, brevity of this
> > message is a key, but also there is a risk that "short" messages are
> > stripped-off any personal touch. I tried to make it not-too long but
> > also not to "dry" either. Not sure if I succeeded.
> >
> > Draft
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386250
> > - any feedback/suggestions are most welcome also if any of you have
> > some personal story to share - feel free :).
> >
> > J.
> >
> > On Sat, Jun 11, 2022 at 9:49 PM Josh Fischer 
> wrote:
> > >
> > > Matt and Jarek,
> > >
> > > I think you both have good ideas.  Getting more people to help with
> this
> > > report will allow for that unique flair.
> > >
> > > I’m looking forward to what comes out in the next report.
> > >
> > > - Josh
> > >
> > > On Sat, Jun 11, 2022 at 1:41 PM Jarek Potiuk  wrote:
> > >
> > > > If we are speaking of the future/experimenting - I think Members
> > Moments
> > > > should be much more personal and something that creates a sense of
> > > > participation in something extraordinary - so I would not compare
> this
> > to
> > > > "board reports". If we can make something that will interest people
> and
> > > > grab their attention and "sense of belonging" - that would be the
> best
> > > > format I think.
> > > >
> > > > I personally always kind of frown upon "repeated" regular reports -
> > always
> > > > showing the same points and in the same "form". They are needed of
> > course,
> > > > but maybe "members moment" should be less informative and more
> > "bringing
> > > > people together" (at least that's how I think about it).
> > > >
> > > > I'd even say as much as this - it would be great if every next "chief
> > > > editor" will add some personal touch to it in the way that the editor
> > feels
> > > > like :). Some "general" content should be similar - but I am thinking
> > about
> > > > inviting someone who would like to say a sentence about what they are
> > proud
> > > > of doing for the Foundation this month. Someone who would not
> normally
> > be
> > > > too "vocal" about it.  I mentioned that initially when this
> discussion
> > > > started. But this might be different thing from the next person next
> > month
> > > > :),
> > > >
> > > > I think that might be the most important "task" of "chief editor" -
> to
> > come
> > > > up with something new and "personal touch" to it.
> > > >
> > > > J.
> > > >
> > > > On Wed, Jun 8, 2022 at 4:51 PM Matt Sicker  wrote:
> > > >
> > > > > I'd imagine some sort of top-line status report could be a level of
> > > > > detail that would work? Essentially, the main part of the email
> would
> > > > > be a few bullet points about what's going on, and a secondary part
> > > > > could go into more details on each point or link to further
> details.
> > > > > I'm imagining the type of report that leadership typically reads in
> > > > > other corporations. Not at the level of detail of board minutes of
> > > > > course.
> > > > >
> > > > > On Wed, Jun 8, 2022 at 7:32 AM Josh Fischer 
> > wrote:
> > > > > >
> > > > > > For sure.  Make it the way you think it will be best for readers.
> > > > > >
> > > > > > On Wed, Jun 8, 2022 at 4:28 AM Jarek Potiuk 
> > wrote:
> > > > > >
> > > > > > > I 

Re: Monthly Member's Moment - July 2022

[Jarek Potiuk]

I also created https://s.apache.org/private short URL. I always lose
far too much time to find it when I need it. This one should be
super-easy to type-in from memory.

On Mon, Jun 27, 2022 at 3:50 PM Jarek Potiuk  wrote:
>
> I prepared a draft which I tried to make a bit more "personal" :). I
> have reached out to infra - to get a bit more personal message of what
> they are doing for the "did you know" section (let's see).
> I thought a bit and looked at past ones and I agree, brevity of this
> message is a key, but also there is a risk that "short" messages are
> stripped-off any personal touch. I tried to make it not-too long but
> also not to "dry" either. Not sure if I succeeded.
>
> Draft 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386250
> - any feedback/suggestions are most welcome also if any of you have
> some personal story to share - feel free :).
>
> J.
>
> On Sat, Jun 11, 2022 at 9:49 PM Josh Fischer  wrote:
> >
> > Matt and Jarek,
> >
> > I think you both have good ideas.  Getting more people to help with this
> > report will allow for that unique flair.
> >
> > I’m looking forward to what comes out in the next report.
> >
> > - Josh
> >
> > On Sat, Jun 11, 2022 at 1:41 PM Jarek Potiuk  wrote:
> >
> > > If we are speaking of the future/experimenting - I think Members Moments
> > > should be much more personal and something that creates a sense of
> > > participation in something extraordinary - so I would not compare this to
> > > "board reports". If we can make something that will interest people and
> > > grab their attention and "sense of belonging" - that would be the best
> > > format I think.
> > >
> > > I personally always kind of frown upon "repeated" regular reports - always
> > > showing the same points and in the same "form". They are needed of course,
> > > but maybe "members moment" should be less informative and more "bringing
> > > people together" (at least that's how I think about it).
> > >
> > > I'd even say as much as this - it would be great if every next "chief
> > > editor" will add some personal touch to it in the way that the editor 
> > > feels
> > > like :). Some "general" content should be similar - but I am thinking 
> > > about
> > > inviting someone who would like to say a sentence about what they are 
> > > proud
> > > of doing for the Foundation this month. Someone who would not normally be
> > > too "vocal" about it.  I mentioned that initially when this discussion
> > > started. But this might be different thing from the next person next month
> > > :),
> > >
> > > I think that might be the most important "task" of "chief editor" - to 
> > > come
> > > up with something new and "personal touch" to it.
> > >
> > > J.
> > >
> > > On Wed, Jun 8, 2022 at 4:51 PM Matt Sicker  wrote:
> > >
> > > > I'd imagine some sort of top-line status report could be a level of
> > > > detail that would work? Essentially, the main part of the email would
> > > > be a few bullet points about what's going on, and a secondary part
> > > > could go into more details on each point or link to further details.
> > > > I'm imagining the type of report that leadership typically reads in
> > > > other corporations. Not at the level of detail of board minutes of
> > > > course.
> > > >
> > > > On Wed, Jun 8, 2022 at 7:32 AM Josh Fischer  wrote:
> > > > >
> > > > > For sure.  Make it the way you think it will be best for readers.
> > > > >
> > > > > On Wed, Jun 8, 2022 at 4:28 AM Jarek Potiuk  wrote:
> > > > >
> > > > > > I am happy to, but I am afraid as chief-editor I will opt for a bit
> > > > longer
> > > > > > digest.
> > > > > >
> > > > > > BTW. I am thinking on how to experiment and see the actual 
> > > > > > usefulness
> > > > of it
> > > > > > rather than "anecdotal feedback". The fact that few people 
> > > > > > complained
> > > > about
> > > > > > messages being too long, does not mean that the others would not 
> > > > > > like
> > > > it a
> > > > > > bit long

Re: Monthly Member's Moment - July 2022

[Jarek Potiuk]

I prepared a draft which I tried to make a bit more "personal" :). I
have reached out to infra - to get a bit more personal message of what
they are doing for the "did you know" section (let's see).
I thought a bit and looked at past ones and I agree, brevity of this
message is a key, but also there is a risk that "short" messages are
stripped-off any personal touch. I tried to make it not-too long but
also not to "dry" either. Not sure if I succeeded.

Draft https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=217386250
- any feedback/suggestions are most welcome also if any of you have
some personal story to share - feel free :).

J.

On Sat, Jun 11, 2022 at 9:49 PM Josh Fischer  wrote:
>
> Matt and Jarek,
>
> I think you both have good ideas.  Getting more people to help with this
> report will allow for that unique flair.
>
> I’m looking forward to what comes out in the next report.
>
> - Josh
>
> On Sat, Jun 11, 2022 at 1:41 PM Jarek Potiuk  wrote:
>
> > If we are speaking of the future/experimenting - I think Members Moments
> > should be much more personal and something that creates a sense of
> > participation in something extraordinary - so I would not compare this to
> > "board reports". If we can make something that will interest people and
> > grab their attention and "sense of belonging" - that would be the best
> > format I think.
> >
> > I personally always kind of frown upon "repeated" regular reports - always
> > showing the same points and in the same "form". They are needed of course,
> > but maybe "members moment" should be less informative and more "bringing
> > people together" (at least that's how I think about it).
> >
> > I'd even say as much as this - it would be great if every next "chief
> > editor" will add some personal touch to it in the way that the editor feels
> > like :). Some "general" content should be similar - but I am thinking about
> > inviting someone who would like to say a sentence about what they are proud
> > of doing for the Foundation this month. Someone who would not normally be
> > too "vocal" about it.  I mentioned that initially when this discussion
> > started. But this might be different thing from the next person next month
> > :),
> >
> > I think that might be the most important "task" of "chief editor" - to come
> > up with something new and "personal touch" to it.
> >
> > J.
> >
> > On Wed, Jun 8, 2022 at 4:51 PM Matt Sicker  wrote:
> >
> > > I'd imagine some sort of top-line status report could be a level of
> > > detail that would work? Essentially, the main part of the email would
> > > be a few bullet points about what's going on, and a secondary part
> > > could go into more details on each point or link to further details.
> > > I'm imagining the type of report that leadership typically reads in
> > > other corporations. Not at the level of detail of board minutes of
> > > course.
> > >
> > > On Wed, Jun 8, 2022 at 7:32 AM Josh Fischer  wrote:
> > > >
> > > > For sure.  Make it the way you think it will be best for readers.
> > > >
> > > > On Wed, Jun 8, 2022 at 4:28 AM Jarek Potiuk  wrote:
> > > >
> > > > > I am happy to, but I am afraid as chief-editor I will opt for a bit
> > > longer
> > > > > digest.
> > > > >
> > > > > BTW. I am thinking on how to experiment and see the actual usefulness
> > > of it
> > > > > rather than "anecdotal feedback". The fact that few people complained
> > > about
> > > > > messages being too long, does not mean that the others would not like
> > > it a
> > > > > bit longer and more useful. I don't know how but will think about it
> > -
> > > I
> > > > > would love to see some objective, measurable data on it to be able to
> > > make
> > > > > decisions.
> > > > >
> > > > > J.
> > > > >
> > > > >
> > > > > On Wed, Jun 8, 2022 at 1:44 AM Josh Fischer 
> > > wrote:
> > > > >
> > > > > > The June newsletter was recently sent to members-announce@a.o.
> > > > > >
> > > > > > Let's target to release the next on July 5, 2022.  Anyone want to
> > > take
> > > > > > point for July?
> > > > > >
> > > > > > Link for next template is below:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/x/Cg31D
> > > > > >
> > > > >
> > > > --
> > > > Sent from A Mobile Device
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> > >
> >
> --
> Sent from A Mobile Device

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

Re: [VOTE] Airflow Providers prepared on June 15, 2022

[Jarek Potiuk]

Yep. I know. Wrong list :). Thanks Bill :)

On Wed, Jun 15, 2022 at 2:44 PM Jarek Potiuk  wrote:

> Hey all,
>
> I have just cut the new wave Airflow Providers packages. This email is
> calling a vote on the release,
> which will last for 72 hours - which means that it will end on Sat 18 Jun
> 14:40:07 CEST 2022.
>
> Consider this my (binding) +1.
>
> This is an ad-hoc release of Google provider with an important bug-fix
> (also oracle provider which is optional dependency of the google provider).
>
> Airflow Providers are available at:
> https://dist.apache.org/repos/dist/dev/airflow/providers/
>
> *apache-airflow-providers--*.tar.gz* are the binary
>  Python "sdist" release - they are also official "sources" for the
> provider packages.
>
> *apache_airflow_providers_-*.whl are the binary
>  Python "wheel" release.
>
> The test procedure for PMC members who would like to test the RC
> candidates are described in
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-by-pmc-members
>
> and for Contributors:
>
>
> https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-by-contributors
>
>
> Public keys are available at:
> https://dist.apache.org/repos/dist/release/airflow/KEYS
>
> Please vote accordingly:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
>
>
> Only votes from PMC members are binding, but members of the community are
> encouraged to test the release and vote with "(non-binding)".
>
> Please note that the version number excludes the 'rcX' string.
> This will allow us to rename the artifact without modifying
> the artifact checksums when we actually release.
>
> The status of testing the providers by the community is kept here:
>
> https://github.com/apache/airflow/issues/24471
>
> You can find packages as well as detailed changelog following the below
> links:
>
> https://pypi.org/project/apache-airflow-providers-google/8.1.0rc1/
> https://pypi.org/project/apache-airflow-providers-oracle/3.1.0rc1/
>
> Cheers,
> J
>

[VOTE] Airflow Providers prepared on June 15, 2022

[Jarek Potiuk]

Hey all,

I have just cut the new wave Airflow Providers packages. This email is
calling a vote on the release,
which will last for 72 hours - which means that it will end on Sat 18 Jun
14:40:07 CEST 2022.

Consider this my (binding) +1.

This is an ad-hoc release of Google provider with an important bug-fix
(also oracle provider which is optional dependency of the google provider).

Airflow Providers are available at:
https://dist.apache.org/repos/dist/dev/airflow/providers/

*apache-airflow-providers--*.tar.gz* are the binary
 Python "sdist" release - they are also official "sources" for the provider
packages.

*apache_airflow_providers_-*.whl are the binary
 Python "wheel" release.

The test procedure for PMC members who would like to test the RC candidates
are described in
https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-the-release-by-pmc-members

and for Contributors:

https://github.com/apache/airflow/blob/main/dev/README_RELEASE_PROVIDER_PACKAGES.md#verify-by-contributors


Public keys are available at:
https://dist.apache.org/repos/dist/release/airflow/KEYS

Please vote accordingly:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason


Only votes from PMC members are binding, but members of the community are
encouraged to test the release and vote with "(non-binding)".

Please note that the version number excludes the 'rcX' string.
This will allow us to rename the artifact without modifying
the artifact checksums when we actually release.

The status of testing the providers by the community is kept here:

https://github.com/apache/airflow/issues/24471

You can find packages as well as detailed changelog following the below
links:

https://pypi.org/project/apache-airflow-providers-google/8.1.0rc1/
https://pypi.org/project/apache-airflow-providers-oracle/3.1.0rc1/

Cheers,
J

Re: Monthly Member's Moment - July 2022

[Jarek Potiuk]

If we are speaking of the future/experimenting - I think Members Moments
should be much more personal and something that creates a sense of
participation in something extraordinary - so I would not compare this to
"board reports". If we can make something that will interest people and
grab their attention and "sense of belonging" - that would be the best
format I think.

I personally always kind of frown upon "repeated" regular reports - always
showing the same points and in the same "form". They are needed of course,
but maybe "members moment" should be less informative and more "bringing
people together" (at least that's how I think about it).

I'd even say as much as this - it would be great if every next "chief
editor" will add some personal touch to it in the way that the editor feels
like :). Some "general" content should be similar - but I am thinking about
inviting someone who would like to say a sentence about what they are proud
of doing for the Foundation this month. Someone who would not normally be
too "vocal" about it.  I mentioned that initially when this discussion
started. But this might be different thing from the next person next month
:),

I think that might be the most important "task" of "chief editor" - to come
up with something new and "personal touch" to it.

J.

On Wed, Jun 8, 2022 at 4:51 PM Matt Sicker  wrote:

> I'd imagine some sort of top-line status report could be a level of
> detail that would work? Essentially, the main part of the email would
> be a few bullet points about what's going on, and a secondary part
> could go into more details on each point or link to further details.
> I'm imagining the type of report that leadership typically reads in
> other corporations. Not at the level of detail of board minutes of
> course.
>
> On Wed, Jun 8, 2022 at 7:32 AM Josh Fischer  wrote:
> >
> > For sure.  Make it the way you think it will be best for readers.
> >
> > On Wed, Jun 8, 2022 at 4:28 AM Jarek Potiuk  wrote:
> >
> > > I am happy to, but I am afraid as chief-editor I will opt for a bit
> longer
> > > digest.
> > >
> > > BTW. I am thinking on how to experiment and see the actual usefulness
> of it
> > > rather than "anecdotal feedback". The fact that few people complained
> about
> > > messages being too long, does not mean that the others would not like
> it a
> > > bit longer and more useful. I don't know how but will think about it -
> I
> > > would love to see some objective, measurable data on it to be able to
> make
> > > decisions.
> > >
> > > J.
> > >
> > >
> > > On Wed, Jun 8, 2022 at 1:44 AM Josh Fischer 
> wrote:
> > >
> > > > The June newsletter was recently sent to members-announce@a.o.
> > > >
> > > > Let's target to release the next on July 5, 2022.  Anyone want to
> take
> > > > point for July?
> > > >
> > > > Link for next template is below:
> > > >
> > > > https://cwiki.apache.org/confluence/x/Cg31D
> > > >
> > >
> > --
> > Sent from A Mobile Device
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Monthly Member's Moment - July 2022

[Jarek Potiuk]

I am happy to, but I am afraid as chief-editor I will opt for a bit longer
digest.

BTW. I am thinking on how to experiment and see the actual usefulness of it
rather than "anecdotal feedback". The fact that few people complained about
messages being too long, does not mean that the others would not like it a
bit longer and more useful. I don't know how but will think about it - I
would love to see some objective, measurable data on it to be able to make
decisions.

J.


On Wed, Jun 8, 2022 at 1:44 AM Josh Fischer  wrote:

> The June newsletter was recently sent to members-announce@a.o.
>
> Let's target to release the next on July 5, 2022.  Anyone want to take
> point for July?
>
> Link for next template is below:
>
> https://cwiki.apache.org/confluence/x/Cg31D
>

Re: June Monthly Members Moment

[Jarek Potiuk]

Sure not a problem - as a chief editor of this edition - feel free to
shorten it :)

On Tue, Jun 7, 2022 at 3:52 PM Josh Fischer  wrote:

> I think we should shorten up the bullet point list.  Last time we sent it
> out, we had reports that the message was a bit much to parse through.  Less
> is more :-).
>
> On Tue, Jun 7, 2022 at 8:29 AM Jarek Potiuk  wrote:
>
> > Thanks for the reminder. Josh. I updated the "mailing list digest"
> >
> > On Tue, Jun 7, 2022 at 3:04 PM Josh Fischer  wrote:
> >
> > > It looks like the members announce list has been set up. I'll be
> sending
> > > this out later today. If anyone has any last minute changes or
> additions,
> > > this is your chance.
> > >
> > > https://cwiki.apache.org/confluence/x/0YyFD
> > >
> > > - Josh
> > >
> > > On Sat, May 21, 2022 at 4:47 PM Josh Fischer 
> > wrote:
> > >
> > > > Thank you.  I remember seeing this, but it totally slipped my mind.
> > > >
> > > >
> > > >
> > > > On Sat, May 21, 2022 at 4:32 PM Sam Ruby 
> > wrote:
> > > >
> > > >> Once members announce is set up, the emails should be sent there.
> > > >> Watch the following JIRA to track status:
> > > >>
> > > >> https://issues.apache.org/jira/browse/INFRA-23290
> > > >>
> > > >> - Sam Ruby
> > > >>
> > > >> On Sat, May 21, 2022 at 4:58 PM Josh Fischer 
> > > wrote:
> > > >> >
> > > >> > Just a heads up.  I plan to send this out June 7, the first
> Tuesday
> > of
> > > >> the
> > > >> > month. It could still use a few details added.
> > > >> >
> > > >> > https://cwiki.apache.org/confluence/x/yBKhD
> > > >> >
> > > >> >
> > > >> > On Mon, May 9, 2022 at 9:25 PM Josh Fischer 
> > > >> wrote:
> > > >> >
> > > >> > > I added some content to the June newsletter.  It could use some
> > > >> attention.
> > > >> > >
> > > >> > > https://cwiki.apache.org/confluence/x/yBKhD
> > > >> > >
> > > >> > > On Tue, May 3, 2022 at 12:26 PM Josh Fischer <
> j...@joshfischer.io
> > >
> > > >> wrote:
> > > >> > >
> > > >> > >> I changed the structure of the Monthly Moments pages:
> > > >> > >> https://cwiki.apache.org/confluence/x/0YyFD
> > > >> > >>
> > > >> > >> Starter page for June is below:
> > > >> > >> https://cwiki.apache.org/confluence/x/yBKhD
> > > >> > >>
> > > >> > > --
> > > >> > Sent from A Mobile Device
> > > >>
> > > >>
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > >> For additional commands, e-mail: dev-h...@community.apache.org
> > > >>
> > > >> --
> > > > Sent from A Mobile Device
> > > >
> > >
> >
>

Re: June Monthly Members Moment

[Jarek Potiuk]

Thanks for the reminder. Josh. I updated the "mailing list digest"

On Tue, Jun 7, 2022 at 3:04 PM Josh Fischer  wrote:

> It looks like the members announce list has been set up. I'll be sending
> this out later today. If anyone has any last minute changes or additions,
> this is your chance.
>
> https://cwiki.apache.org/confluence/x/0YyFD
>
> - Josh
>
> On Sat, May 21, 2022 at 4:47 PM Josh Fischer  wrote:
>
> > Thank you.  I remember seeing this, but it totally slipped my mind.
> >
> >
> >
> > On Sat, May 21, 2022 at 4:32 PM Sam Ruby  wrote:
> >
> >> Once members announce is set up, the emails should be sent there.
> >> Watch the following JIRA to track status:
> >>
> >> https://issues.apache.org/jira/browse/INFRA-23290
> >>
> >> - Sam Ruby
> >>
> >> On Sat, May 21, 2022 at 4:58 PM Josh Fischer 
> wrote:
> >> >
> >> > Just a heads up.  I plan to send this out June 7, the first Tuesday of
> >> the
> >> > month. It could still use a few details added.
> >> >
> >> > https://cwiki.apache.org/confluence/x/yBKhD
> >> >
> >> >
> >> > On Mon, May 9, 2022 at 9:25 PM Josh Fischer 
> >> wrote:
> >> >
> >> > > I added some content to the June newsletter.  It could use some
> >> attention.
> >> > >
> >> > > https://cwiki.apache.org/confluence/x/yBKhD
> >> > >
> >> > > On Tue, May 3, 2022 at 12:26 PM Josh Fischer 
> >> wrote:
> >> > >
> >> > >> I changed the structure of the Monthly Moments pages:
> >> > >> https://cwiki.apache.org/confluence/x/0YyFD
> >> > >>
> >> > >> Starter page for June is below:
> >> > >> https://cwiki.apache.org/confluence/x/yBKhD
> >> > >>
> >> > > --
> >> > Sent from A Mobile Device
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >> --
> > Sent from A Mobile Device
> >
>

Re: [Question]About promotion ambassador

[Jarek Potiuk]

100% that.

On Fri, May 13, 2022 at 9:31 PM  wrote:

> On Fri, 2022-05-13 at 20:07 +0100, Geertjan Wielenga wrote:
> > I’d love to know who the specific people are that I should reach out
> > to per
> > Apache project to discuss collaboration around events, promotions of
> > our
> > projects, etc.
> >
> > If the answer to the above is “write to their mailing list” or
> > “everyone”,
> > etc, then no that’s not what I mean.
>
> I tend to think that the answer *should* be write to the mailing list,
> but that *also* there should be people who consider it their role to
> step up and answer those questions.
>
> Why both? Because we do things in the view of the entire community, so
> that 1) people can see answers to questions that they may have, but
> haven't asked yet and 2) people see the conversation and think "I could
> do that too" and then step in the next time.
>
> When the answer is "Email Larry", then 1) only Larry sees the questions
> and they don't benefit anybody else and 2) the rest of the community is
> told, implicitly, back off, that's not your cookie.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [Question]About promotion ambassador

[Jarek Potiuk]

What's the problem with reaching out to the dev@ ? This is a great thing to
do.

I keep on explaining people when they reach me (or anyone else) directly
for help in any subject in Airflow that they are doing it wrong for three
reasons:

1) they do not let others, who feel like and are able to help them, to
answer, effectively limiting their own options
2) they demand exclusive attention from those they reach out to directly
(and the people reached out to can be sick, unavailable, busy, have no
time, take vacations), by reaching them directly you put a pressure on them
- you should be aware of that.
3) they do not let anyone else to learn from their reaching out because it
is done in private

This is IMHO, wrong on basically all levels where community is there.

I think people should learn more to ask publicly for help. Doing so is not
a sign of weakness, it's a sign for maturity - you are mature enough to
know that you do not know things and reach out to a wider audience for
help. It also forces you to specify precisely what you ask for and this is
great.

J.





On Fri, May 13, 2022 at 9:07 PM Geertjan Wielenga
 wrote:

> I’d love to know who the specific people are that I should reach out to per
> Apache project to discuss collaboration around events, promotions of our
> projects, etc.
>
> If the answer to the above is “write to their mailing list” or “everyone”,
> etc, then no that’s not what I mean.
>
> Without a single point of advocacy contact per project, which would be 100%
> different to the current fragmented state, we will continue in the same way
> as before in the current fragmented state.
>
> Also happy to do this outside Apache if needed, e.g., Foojay.io which I am
> heavily involved in, but ideally we could achieve this within Apache and,
> no, not within current structures etc etc etc, but in a new way, please.
>
> Gj
>
>
> On Fri, 13 May 2022 at 19:44, Jarek Potiuk  wrote:
>
> > Speaking of being ambassador - very much yes to do it, very much no to
> > "official status" of being one (since I was called by Rich).
> > IMHO. You are an ambassador or "evangelist" because you do it not because
> > you have a "title" to do it. There is absolutely no benefit or
> entitlement
> > of being appointed as an ambassador.
> > If you do it, and do it well, you will be known as an ambassador. What
> else
> > is needed? Why do you need a title?
> >
> > J.
> >
>

Re: [Question]About promotion ambassador

[Jarek Potiuk]

Speaking of being ambassador - very much yes to do it, very much no to
"official status" of being one (since I was called by Rich).
IMHO. You are an ambassador or "evangelist" because you do it not because
you have a "title" to do it. There is absolutely no benefit or entitlement
of being appointed as an ambassador.
If you do it, and do it well, you will be known as an ambassador. What else
is needed? Why do you need a title?

J.

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

One small comment.

Just the fact that we are discussing CCLA vs. ICLA is an indication that an
average contributor who wants to enter into a relationship with a corporate
customer w/regards to OSS/Apache related work is at a complete loss.

It means that we BADLY need a legal entity that will handle the legal side
of the relationship.

I've added CCLA only because my lawyers advised me that my Slovakian
company that I use for my invoicing (which I solely own) should have it  -
because I issue invoices by this company.
But I do not expect any of my corporate customers to sign CCLA and put my
name there  if I am an independent contractor working for them, Being an
independent vendor/contractor is very different from being an employee in
this case. That is next to impossible to get CCLA with your name in it when
you are not an employee. Even if you are an employee in a big company you
are not likely to get it. So CCLA is generally out of the discussion here.
ICLA is what matters and recognition of it is (IMHO) something that should
be in a contract with any vendor. That's where I see the role of "OCC +
ASF" which could provide legal framework and support for it - to any
contributor who does not even understand what we are talking about.

 J.

On Wed, May 11, 2022 at 8:52 PM Dave Fisher  wrote:

>
>
> > On May 11, 2022, at 11:43 AM, Matt Sicker  wrote:
> >
> > A CCLA isn't sufficient for contributions at Apache, though. An ICLA
> > is always required to be a committer, for example, regardless if every
> > breath you take is copyrighted by your employer. A CCLA can be useful
> > for documenting whether a corporation has explicitly approved various
> > individuals they employ to contribute, but it's more of a comfort
> > thing. If you read the ICLA, you'll see this bit:
> >
> >   You represent that you are legally entitled to grant the above
> >   license. If your employer(s) has rights to intellectual property
> >   that you create that includes your Contributions, you represent
> >   that you have received permission to make Contributions on behalf
> >   of that employer, that your employer has waived such rights for
> >   your Contributions to the Foundation, or that your employer has
> >   executed a separate Corporate CLA with the Foundation.
> >
> > The CCLA is optional because the ICLA already requires that you've
> > gotten approval from any owners. The CCLA can formally document this,
> > but it's already implied by the ICLA.
>
> True, but (1) I was a brand new committer and (2) it made it clear that my
> employer could NOT change their mind arbitrarily.
>
> I probably could have argued that the company that acquired my employer,
> my new employer, was bound by the CCLA … the ASF may only require an ICLA,
> but an individual may prefer that a CCLA is filed, That use case and
> language is in the ICLA BTW.
>
> > or that your employer has
> >   executed a separate Corporate CLA with the Foundation.
>
>
> I’m not sure why you’re arguing this? Are CCLAs a burden to the Secretary?
>
> >
> > On Wed, May 11, 2022 at 12:54 PM Dave Fisher  wrote:
> >>
> >> When I first signed an ICLA in about 2008 I made sure that I had the
> company I worked for sign a CCLA that named individuals. This was for my
> protection otherwise my ASF work was work for hire.
> >>
> >> Later that company was acquired and my position was senior enough that
> all of my work belonged to them.
> >>
> >>> On May 11, 2022, at 10:37 AM, Matt Sicker  wrote:
> >>>
> >>> Small point of clarification: only the ICLA matters at Apache since
> >>> contributions are made by individuals. The CCLA is provided for
> >>> companies so perplexed by this concept that they feel the need for
> >>> more paperwork.
> >>>
> >>> On Wed, May 11, 2022 at 4:36 AM Jarek Potiuk  wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> I guess my point about this is, that small startups usually have
> problems
> >>>>> of getting contracts.
> >>>>>
> >>>>> I can't count the occasions, where I generated leads at a conference.
> >>>>> After the conference, when we were discussing moving forward, 95% of
> all of
> >>>>> these died because the customers can't do business with such small
> >>>>> companies.
> >>>>>
> >>>>>
> >>>> This is also my assessment of where  the problem is. I think building
> >>>> relationships and finding customers in an OSS world is relatively
> easy if
> >>>&

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

>
>
> I guess my point about this is, that small startups usually have problems
> of getting contracts.
>
> I can't count the occasions, where I generated leads at a conference.
> After the conference, when we were discussing moving forward, 95% of all of
> these died because the customers can't do business with such small
> companies.
>
>
This is also my assessment of where  the problem is. I think building
relationships and finding customers in an OSS world is relatively easy if
you are transparent, honest, do your job well and you are open to speak,
you make sure you stand out of the crowd and you are generally proud of
what you do (yes Chris - those all things are about you too :D).

It's turning them into a regular invoice paid every month is where the
difficulty is.

However I think we need to really understand where the "can't do business"
comes from. My view on this:

1) The businesses have established procurement processes and you have to
"fit" - in most cases there are a number of conditions:
- you have to "be on the list" of the approved vendors
- in many you have to sign certain agreements that you do not "child
labour", "bribery" etc. and similar thing (basically because public
companies have to report that their vendors are "ok" to the auditors
- in many cases the business have to have someone to "sue" in case
there is a damage or have some other indemnification in place - (what if
the vendor does harm to our customers and we get sued)
- there is also a check who is the beneficiary owner (money laundering)
W1-BEN forms in US when you have "individuals"
- also - and this is more important recently - there is a check if your
company does not fall into any of the sanctions imposed by the political
decisions
- there are a number of legal requirements (TAX Id registrations etc.)

Having an entity that is "known" to the customer and "big" and can provide
such guarantees is crucial otherwise it's a big effort to pass that step.
Here Both "Support Inc." and "Open Collective + ASF as fiscal host" - if we
can think about the two models, would likely work well. The "burden" of
verifying those is shifted to OpenCollective and ASF joint effort and I
think it should be feasible to put both OC and ASF as "accepted vendor
combo" for most big players. And for each player it would have to be done
once to enable all projects basically.

2) We also have to remember that people who we contact as potential
customers often are not familiar with those processes - and even if they
"want" to work with you - this might be the first time they approach it and
it can take them MONTHS to get it sorted out.
I can - again - give a very good example. I mentioned "contract"
negotiations before - and it  is an interesting one. The prospective
customer people really wants to work with me. I really love what they do
and I have great contact there who is willing to take on all the complexity
of managing the OSS <> Company relations between me and the company - we
are also friends and worked together on a number of initiatives in the
project (successfully) and we both want to work together. And the manager
of my friend and his manager are fully supportive. And ~ 2 months ago the
joint statement was "we really want to start working together basically
next week". We still have no contract signed today. We know the price, we
know how much time I will focus on with the customer, we know what the
needs of the customer are. We know big parts of it will end up as good
community contributions. EVERYTHING is in place. But they never ever had a
contract with someone like me. I have a requirement that the contract from
the customer is explicit about my ICLA (and my self-owned company CCLA) and
this is with the lawyers of the company now.

Here - this is something that 1) will make easier - because (hopefully) we
could work out a template contract and having bigger entity (whether
Support Inc or OC + ASF Combo) we could probably have some established
"service" with all the documents prepared, and all the answers given and
even some guidance to our "partners" at the corporates on how they can
clear their processes faster. But there is one caveat (see point 3) as our
relation is a bit different.

3) The 2) might take much longer  mostly because we - OSS contributors -
have a different type of relationship than regular vendors. For most of the
vendors, big businesses have some expectations that we cannot meet and we
fall into "legalities" and contract signing.

There are two kinds of those:

* we cannot guarantee that whatever the customer wants will be fulfilled
when we contribute to ASF projects. Most big players look at such a
relation from "I pay - I demand" and most of the internal audits will have
a hard time on accepting a contract where there is no "deliverable" that
the company can "demand to complete". I found this extremely hard to
negotiate in the past. Usually it ends up with some kind of "blurry"
statement 

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

> I thought the point of this idea was to make OSS development sustainable,
not to train us all to be founders of startups.

Yes. I think this is a really nice summary of what my point is. Thanks for
putting it so succinctly.
I personally think if you want to make a living out of the OSS
contribution, you actually have to think like a small startup founder
(where your contribution job is your "product").

J.

On Tue, May 10, 2022 at 6:01 PM Matt Sicker  wrote:

> I thought the point of this idea was to make OSS development sustainable,
> not to train us all to be founders of startups. The bar to contributors is
> already high enough as it is (who has the time, energy, and knowledge to
> spend here? I’d assume mostly well-off people).
>
> For comparison, projects developed by a company like Red Hat benefit from
> name recognition of Red Hat more so than any individual developers there. I
> get the impression that a sort of Support Inc would leverage name
> recognition and connections with the people who already do the work.
>
> If projects need their own companies to do all this, then only end user
> applications will thrive at Apache, and all the libraries and developer
> tools will suffer. Applications depend on these things, but that’s a
> problem for next quarter, not the current one.
>
> —
> Matt Sicker
>
> > On May 10, 2022, at 09:02, Jarek Potiuk  wrote:
> >
> > So I think we are talking about two different approaches then and hence
> the
> > mi understanding. I was thinking more about solving all the
> > legal/administrative barriers.
> >
> > At least that's what I see as a much, much bigger problem than actually
> > doing marketing and finding stakeholders willing to pay for your job (AKA
> > "selling" your job).
> >
> > I think it would be great to identify what is **really** the problem we
> > want to solve and what is the biggest obstacle for those who want to earn
> > money from contributing (I think the survey from the diversity team might
> > help us in understanding that).
> >
> > My personal experience - I think no-one will be able to sell and promote
> > your job as good as you. And when you do a good job, it's easy. Just
> speak
> > about it - at conferences. blog posts, meetups, conferences. There is no
> > better marketing. My personal experience is that for individuals and
> small
> > group of people the best salespeople are those who do the job - and as
> long
> > as they do it in a smart way, and what they sell is a small team of
> people
> > or their own job - this is much more efficient than "hiring" someone to
> do
> > the job. I've been doing that for years in my previous company and we
> tried
> > several times with marketing/sales people and it never worked out until
> we
> > hit some 50-60 people - until then the sales and marketing people who had
> > to learn from us what and how to sell took more time and energy from us
> > than they brought revenue.
> >
> > Being an engineer, while speaking about what we do in a passionate way
> with
> > transparent and sincere statements, and occasional, very focused and in
> > short time spans "sales efforts" (usually revolving around tech
> conferences
> > that I took part on, spoke at or organized) - I personally brought my
> > company maybe 30-40% high-margin revenue in the first few years of our
> > company when we grew from 10 to 40 people. At the same time sales and
> > marketing attempts we did, brought maybe 5% of rather low-margin revenue
> or
> > even loss-inducing revenue. The rest was our CEO's job (also an engineer
> > but unlike me he gave up being an engineer to be CEO but he "was" the
> > company). The best sales are when your customer does not feel you are
> > selling something.
> >
> > Yeah. we dreamt that "we will bring those sales and marketing people and
> > they will do everything for us". But with several attempts it turned out
> -
> > at least for me and my companies in the past - a dreampipe until we got
> the
> > right scale. And even when it did  the amount of time spent be (various)
> > engineers on marketing and sales was about the same as before - it was
> just
> > amplified by the sales/marketing teams we had - and it was needed because
> > we had more people. Simply, I strongly believe no matter what, if you
> want
> > to sell your job, you yourself have to spend time on selling and
> marketing.
> > Either doing it or helping others to understand what you do (but the
> latter
> > is far less efficient until you hit the right multiplier). And I

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

eone better are slim, and also revenue brought will
be small so it's not worth any more effort from their side. However if
there is big project with multiple commmiters, stakeholders and interested
parties - this might be much more interesting for them, because  they can
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 
wrote:

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

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

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

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

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 available for any project, no matter what size it is.
>> >>
>> >> Yes, it could just be a new company and wouldn't need to have the
>> blessing
>> >> of the ASF, but then there would be yet another Support Inc.
>> Effectively
>> >> all splitting the cake up into smaller pieces hereby keeping each one
>> from
>> >> not reaching the breaking point in which things would start running on
>> >> their own.
>> >>
>> >> That's why I thought: Something with explicit ties to the ASF could
>> >

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

> 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 available for any project, no matter what size it is.
> >>
> >> Yes, it could just be a new company and wouldn't need to have the
> blessing
> >> of the ASF, but then there would be yet another Support Inc. Effectively
> >> all splitting the cake up into smaller pieces hereby keeping each one
> from
> >> not reaching the breaking point in which things would start running on
> >> their own.
> >>
> >> That's why I thought: Something with explicit ties to the ASF could
> >> benefit from being considered the “official” way to get support or at
> least
> >> the way the ASF considers to be absolutely in-line with its policies and
> >> might help reaching the critical mass needed to work.
> >>
> >> 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.
> >>
> >> In general, I’d be happy, if an existing company could provide this
> >> service, but as I mentioned, my condition for accepting this as a
> solution
> >> would be that every project wanting to do so, could do their business
> >> though them. Tidelift has proven to only select the filet parts, which I
> >> consider inacceptable for being considered as being a solution to this
> >> problem.
> >>
> >> And to what Jarek said. 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.
> >>
> >> Chris
> >>
> >>
>

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

> 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 
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 available for any project, no matter what size it is.
>
> Yes, it could just be a new company and wouldn't need to have the blessing
> of the ASF, but then there would be yet another Support Inc. Effectively
> all splitting the cake up into smaller pieces hereby keeping each one from
> not reaching the breaking point in which things would start running on
> their own.
>
> That's why I thought: Something with explicit ties to the ASF could
> benefit from being considered the “official” way to get support or at least
> the way the ASF considers to be absolutely in-line with its policies and
> might help reaching the critical mass needed to work.
>
> 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.
>
> In general, I’d be happy, if an existing company could provide this
> service, but as I mentioned, my condition for accepting this as a solution
> would be that every project wanting to do so, could do their business
> though them. Tidelift has proven to only select the filet parts, which I
> consider inacceptable for being considered as being a solution to this
> problem.
>
> And to what Jarek said. 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.
>
> Chris
>
>
>
>
> -Original Message-
> From: Jarek Potiuk 
> Sent: Montag, 9. Mai 2022 11:49
> To: dev@community.apache.org
> Subject: Re: [DISCUSS] Crazy or good Idea?
>
> Very good points Roman. I think it's great to think about it with the
> building business "mindset" - this is the only way it can actually succeed.
> But maybe we do not have to go this way.
> The #1 seems much more attractive and there are other options.
>
> I think Open Collective is as close as it can be to the 'Apache Way" when
> it comes to enablers and the economy of scale is already there I think.
>
> I've been participating with several campaigns now through them - they
> seem to be they don't even want to "own the relation" between the
> "collective individuals" and "sponsors".
>
> They seem to be pretty much 100% of what I consider as "enabler" -
> https://opencollective.com/how-it-works:
>
> * Managing payments and admin
> * enabling easy marketing and promotion
> * basically enabling a group of people to establish effective, repeating
> campaigns and building long-lasting relationships generally focused on
> "doing good".
> * the "collectives" decide themselves on the scope and conditions of the
> campaign they run - but eventually it's all based on the reputation of the
> people who run the collective to be trusted by the  supporters.
> * you can organize your "collective" there without legally incorporating
> it (by a group of individuals) and get anyone to support it.
>
> I think the only remaining question is - how feasible and attractive such
> "collective" might be for Sponsoring companies.
>
> And there is an interesting option that might be actually a good response
> to it and a way how such a collective **might** get reputation.
> The Apache Software Foundation **could** become a "Fiscal Host" there
> https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts - 

Re: [DISCUSS] Crazy or good Idea?

[Jarek Potiuk]

Very good points Roman. I think it's great to think about it with the
building business "mindset" - this is the only way it can actually succeed.
But maybe we do not have to go this way.
The #1 seems much more attractive and there are other options.

I think Open Collective is as close as it can be to the 'Apache Way" when
it comes to enablers and the economy of scale is already there I think.

I've been participating with several campaigns now through them - they seem
to be they don't even want to "own the relation" between the "collective
individuals" and "sponsors".

They seem to be pretty much 100% of what I consider as "enabler" -
https://opencollective.com/how-it-works:

* Managing payments and admin
* enabling easy marketing and promotion
* basically enabling a group of people to establish effective, repeating
campaigns and building long-lasting relationships generally focused on
"doing good".
* the "collectives" decide themselves on the scope and conditions of the
campaign they run - but eventually it's all based on the reputation of the
people who run the collective to be trusted by the  supporters.
* you can organize your "collective" there without legally incorporating it
(by a group of individuals) and get anyone to support it.

I think the only remaining question is - how feasible and attractive such
"collective" might be for Sponsoring companies.

And there is an interesting option that might be actually a good response
to it and a way how such a collective **might** get reputation.
The Apache Software Foundation **could** become a "Fiscal Host" there
https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts - i.e. an
entity that holds the funds and manages the legal/bank account but it is
not involved in any way with the contracts and decisions of the
"collective".

A fiscal host is a legal company or individual who holds a Collective’s
funds in their bank account and can generate invoices and receipts for
supporters and sponsors. You can think of a fiscal host as an umbrella
organization for the Collectives in it.

I think such "Fiscal Host" is precisely the "missing" link we did not have
so far. Of course it needs to be checked from the legal side - what is the
responsibility and whether it is in-line with the ASF bylaws and mission,
but seems like becoming "Fiscal Host" in open collective is precisely what
the ASF could do. And then it gets even better, because such Fiscal Host
might host mutliple collectives:
- one per PMC for example - why not
-  "Security at the ASF" - for multiple projects

And many others. The nice thing there is that IF the ASF will not charge
the collectives, OpenCollective does not charge their 15% cut. And any
collective can "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 

Re: Naming/Branding: First Steps

[Jarek Potiuk]

 As mentioned elsewhere, one of the possibilities for the middle ground 3)
is respectful, proactive dissociation from the Apache Tribes, leaving only
the name in the scope of the "software". Including the logo, re-cutting
movies and everything we can track where the "Apache" is currently in any
way linked to the Apache Tribe (while respectfully mentioning the origin
and that we detached from this consciously).

PRO:
* relatively easy to implement (comparing to full speed ahead at least)
* allows the community to pay respect while not really following
"reparation" (implicitly reaffirming that there is no actual/intentional
damage to the Tribe)
* allows us to keep the valuable brand developed over 20 years
* shows that the ASF responds to concerns and does not "sweep such things
under the rug"

CON:
* not everyone sees it is possible to de-attach
* a number of people will still have concerns
* might not prevent us from litigation for the "past" even if we manage to
de-associate

Also I'd argue (just a little) about the "2) PRO: This removes any and all
risk in perpetuity" - it does not remove all risk. Still it is possible
that someone litigates the "renamed" ASF use of Apache for the past 20
years. The past is there and we are not able to change it. I think while
renaming might decrease the risk significantly, it does not remove it
completely. If someone wants potential damages repaired, it's a bit the
same as in case of de-associating (but without the possibility of Cease &
Desist - so yeah - it is much less of a problem if it happens and can only
result - potentially - in having to pay the damages).

J.


On Fri, May 6, 2022 at 9:14 PM me  wrote:

> Our legal folks have responded (quickly!).
>
> I’m quoting the recommendation here:
>
> If someone wants to take ASF to court over this, we can
> worry about it, then. Until then, there isn't really anything we can do
> about it other than try to be as benign as possible toward those people
> who might consider such litigation.
>
>
> Benign as possible can be read in a number of different ways, depending on
> how we are defining the scope (federally recognized Apache nations, all
> Apache nations, all indigenous tribes, etc.)
>
>
>
> 1.) (Extreme 1) Do nothing. Without a registered complaint from the tribe,
> this is analogous to an “If it ain’t broke don’t fix it, approach”.
>
> PRO: We don’t bring attention to a problem by communicating a scenario
>
> CON: There has been communicated social impact complaints that aren’t
> being addressed. There is a latent risk.
>
>
>
> 2.) (Extreme 2) Do everything. Just change the name and the license
> proactively. This is a “full speed ahead” proactive effort.
>
> PRO: This removes any and all risk in perpetuity
>
> CON: The level of effort is substantial, and it may exceed social
> responsibility.
>
>
>
> 3.) Middle ground. Not sure what that is.
>
>
>
> Cheers!
>
> Ed
>
>
>
>
>
>
>
>
>
>
> From: Owen Rubel 
> Reply: dev@community.apache.org 
> Date: May 6, 2022 at 12:24:54
> To: dev@community.apache.org 
> Subject:  Re: Naming/Branding: First Steps
>
> Bravo. Brilliant.
>
>
> Owen Rubel
> oru...@gmail.com
>
>
> On Fri, May 6, 2022 at 7:26 AM me  wrote:
>
> > Happy Friday/Saturday esteemed colleagues and collaborators!
> >
> > I kicked off the first steps by reaching out to the legal team to
> > understand the risk/worst case scenario. I’m attempting to gain a
> better
> > understanding to the question: “What if the choice is taken away from
> us,
> > through litigation?”
> >
> > My thought process is the following:
> >
> > Irrespective of social climate, level of effort, etc. there is a worst
> > case scenario represented by the ever present risk. Before we embark on
> any
> > journeys of epic proportions for the greater good, it’s helpful to
> define
> > the stakes and understand our primary responsibilities: our community.
> >
> > I think it’s a fair assumption that this will help level set
> conversations
> > going forward, as well as to provide us a next question: “Given the
> defined
> > risk, what is its magnitude?” (i.e. is it a 1 in a billion lightning
> > strike, or a 50/50 coin flip).
> >
> > —
> >
> > That said, I think there is a derivative of Owen’s statements we have
> to
> > consider.
> >
> > Asking a question to parties who haven't considered that question
> > inevitably runs the risk of changing their perspective. If there is a
> gun
> > to be jumped, this is most likely it. If I can make a request of those
> > involved thus far, can you sleep on this and think about it? I think
> it’s
> > something we need to consider internally so that any outreach is
> approached
> > with care.
> >
> > It might be worth doing some internal research on Apache culture
> (nothing
> > exhaustive, but enough for us to understand tribal values) before
> > performing outreach (or in the extreme, from performing it altogether).
> At
> > the very least this can help us navigate away from areas that may
> induce
> > 

Re: A way to keep the name

[Jarek Potiuk]

I think it's a good idea to make such a fund or simply make sure that
existing efforts (TAC, Outreachy engagement) have some deliberate and
conscious actions in this direction - knowing the past association - and
showing the respect and following the original mindset of people who
created the foundation.

Just one comment here - I stated my opinion in the member's discussions -
that's my personal view of course, that there is nothing to repair as there
is no damage and simply de-association of Apache name while also showing
the respect and engage community to actively work on de-associating is a
better way of handling the issue than any repair.

Using the word "reparation" here is certainly not the one I'd use. It might
be good will and sign of respect, but in no-way it should bring any
obligation on the ASF.

If I see "Association with permission" is extremely dangerous for the
foundation that worked 20 years on the brand being it's most valuable asset
(without the real piggy-backing on the Apache Tribe in order to build the
reputation). Just having "permission" from others on the important asset of
the ASF foundation brand depending on non-member decisions might also be
illegal from the foundation bylaws (I am not a lawyer and certainly do not
know much about US law). This would basically mean that we put the fate of
the foundation in the hands of non-members.

So while it would be great to show outgoing engagement from the members to
reach out with some efforts, this should not be seen as "reparation" or
"obligation". I think it is a very asymmetrical approach to think in those
terms.

It's one thing to react to concerns of people who feel one way and very
different to be "responsible for damage" (which reparation is basically
about).

J.


On Thu, May 5, 2022 at 6:20 AM Walter Cameron <
walter.li...@waltercameron.com> wrote:

> > members of the Apache Nation (defined by the eight tribes)
>
> Choosing to use federal recognition as the litmus test for eligibility will
> exclude many impacted by ASF’s appropriation of the term.
>
> There are also state recognized tribes such as the Choctaw-Apache Community
> of Ebarb who don’t yet have federal recognition. It’s also important to
> keep in mind that many Native people live in Native communities and are
> affected by such labels and stereotyping but for whatever reasons might not
> be officially enrolled in their tribe.
>
> Any sort of criteria for determining eligibility for reparations should be
> as broad as possible.
>
> I would also like to echo Ed’s warnings of the risks of time here. As we
> are not Apache people ourselves, we are just a bunch of people that signed
> up for a mailing list, we are not as attuned to the use of the term and how
> people respond to it.
>
>
> On Wed, May 4, 2022 at 10:39 AM me  wrote:
>
> > This was somewhat covered (at a much higher level).  This falls into the
> > category of ‘association with permission’. It’s somewhere between
> > disassociation and what Jeep is doing (which is to determine if a problem
> > exists w/ the specific tribe.)
> >
> > Each circumstance is unique. I looked through Jeep’s materials, and they
> > have no documentation that links them directly to the Cherokee nation. We
> > do. With such an explicit relationship, perception (of that relationship)
> > is fairly black and white. On the flip side, it does give us more
> > steps/milestones if we do define a problem.
> >
> > I think what is challenging to communicate is the difference between the
> > Washington/Cleveland sports team cases, and Jeep/ASF.
> >
> > Washington/Cleveland is cut and dry, because their mascots were a
> > disparaging term. (i.e. like Esk*mo is to the Inuit).
> >
> > ASF/Jeep are using a tribe name, which w/o context has no connotation
> > other than an identifier. However, the usage and context of the name is
> > where perception comes in. Once we start doing things under the umbrella
> of
> > the name, there is an association or linkage. If the tribal nations are
> > against what we “do”, based on values of some tribes (at least the ones I
> > share DNA with), trying to “buy” the name may be considered extremely
> > offensive.
> >
> > It’s also worth considering that it is an ongoing risk. What is ok today
> > might not be tomorrow. It’s entirely possible that we take a direction
> that
> > no longer aligns with what the nations consider acceptable values.
> >
> > I would love to see some form of positive relationship fostered that
> > allows an organization to create a respectful relationship (maybe us!). I
> > personally find that to be a more interesting direction than we appear to
> > be headed globally. (I suppose this is incredibly ironic when you
> consider
> > that I’m proposing social unification which is often considered to be the
> > reciprocal of tribalism)
> >
> >
> >
> >
> > From: Andrew Wetmore 
> > Reply: dev@community.apache.org 
> > Date: May 4, 2022 at 14:05:48
> > To: dev@community.apache.org 
> > 

Re: It’s time to change the name

[Jarek Potiuk]

Emphasise - Empathise of course :)

On Wed, May 4, 2022 at 6:17 PM Jarek Potiuk  wrote:

> Cool.
>
> I am not really convinced by the total ~ 1 % of the "Trillions" movie
> where the scenery is mostly with Greg recorded apparently close to the
> place where he lives - in Austin Texas. Yeah I know - it sets the tone
> maybe and the music is a bit suggestive.
> But (at least when I look at it) it's more accidental and
> subconscious than intended IMHO and still can be reverted by
> conscious actions - for example re-cutting and re-posting the movie if it
> bothers people who are much more "into this" (which we BTW would have to do
> anyway if we want to change the logo as it is there through entire movie in
> the bottom-right corner).
>
> And I think maybe the "de-association" might be the achievable interim
> step on the road to full rebranding. Or maybe we can treat it as an
> experiment that can be done in a short time without engaging multiple
> people and starting a machinery for decades-long rebranding process. The
> big risk with such huge projects to undertake is that they likely might get
> stalled in the "idea" stage when there will not be enough time, power,
> energy, will-power of people who would like to be engaged or it might be
> prolonged by procedural issues and "impossibilities". As much as I might
> emphasise with someone who is dead clear on "we have to go full on
> rebranding", the fact of life is that such huge efforts more often than not
> simply fail and eventually 0% of the goal is achieved.
>
> At the end we can deliberate a lot and have opinions, but if we can do
> something "faster" that gets us into the right direction, and if we can
> rather quickly verify the direction (and maybe running some verification,
> polls, reaching out after that to see if we achieved something).
>
> As much as I am fully for "disagree but engage" (my version of the
> saying), I am all for experimenting and trying to fix things incrementally
> (and seeing effect of it on the way) rather than venturing in to decades
> long effort when we do not even know if it's needed and whether maybe 90%
> of the effect can be achieved with 10% of the effort and time. I think
> "achievability" is a very important aspect of this discussion and I'd only
> appeal to the reason of people doing it (maybe including myself at some
> time) to be aware that going "full rebranding" is not the only option, and
> if the goal is to improve things, it might fail at "0%" stage if it is the
> only option considered.
>
> J.
>
> On Wed, May 4, 2022 at 4:17 PM me  wrote:
>
>> Bertrand, this is fantastic.
>>
>> I’m more than happy to assist w/ a strategy, approach, prep and board
>> preso.
>>
>> Something that is worth mentioning up front is that whatever the outcome,
>> there are going to be protractors and detractors. Unanimous support is
>> challenging to achieve, and quite rare. Whatever the outcome, we have to be
>> prepared to “disagree and commit” (i.e. support the majority even if the
>> outcome isn’t specifically what we had hoped for).
>>
>> There are many possibilities from no change to wholesale rebranding (even
>> some we haven’t thought of). The cool thing about change is that as long as
>> we remain open to it, changes today don’t stop us from making more changes
>> tomorrow!
>>
>>
>>
>> From: Bertrand Delacretaz 
>> Reply: dev@community.apache.org 
>> Date: May 4, 2022 at 05:10:53
>> To: dev 
>> Cc: Andrew Musselman 
>> Subject:  Re: It’s time to change the name
>>
>> Hi,
>>
>> (Bcc people who have been active in the wiki page mentioned below)
>>
>> Le ven. 29 avr. 2022 à 16:14, Andrew Musselman  a écrit
>> :
>> > ...Can I propose an outreach to some Apache tribe governments so we can
>> open a
>> > dialog with them directly, and start to understand what their official
>> > experience of the ASF branding is?...
>>
>> I think that would be very useful, helping us hear from leaders who
>> have standing in the cause.
>>
>> Note that this was discussed earlier at [1] which has an initial list
>> of Apache Nations that could be contacted. Access restricted to ASF
>> members as the page contains contact information.
>>
>> If a team of ASF members wants to make this happen, I'm willing to
>> bring the topic to the Board and would support giving that team an
>> official status to help them do that outreach.
>>
>> Next step would be for you and other interested Members to form a team
>> and present their action plan to the Board.
>>
>> -Bertrand
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/ASFP/Outreach+to+the+Apache+Nations
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>>

Re: It’s time to change the name

[Jarek Potiuk]

Cool.

I am not really convinced by the total ~ 1 % of the "Trillions" movie where
the scenery is mostly with Greg recorded apparently close to the place
where he lives - in Austin Texas. Yeah I know - it sets the tone maybe and
the music is a bit suggestive.
But (at least when I look at it) it's more accidental and subconscious than
intended IMHO and still can be reverted by conscious actions - for example
re-cutting and re-posting the movie if it bothers people who are much more
"into this" (which we BTW would have to do anyway if we want to change the
logo as it is there through entire movie in the bottom-right corner).

And I think maybe the "de-association" might be the achievable interim step
on the road to full rebranding. Or maybe we can treat it as an experiment
that can be done in a short time without engaging multiple people and
starting a machinery for decades-long rebranding process. The big risk with
such huge projects to undertake is that they likely might get stalled in
the "idea" stage when there will not be enough time, power, energy,
will-power of people who would like to be engaged or it might be prolonged
by procedural issues and "impossibilities". As much as I might emphasise
with someone who is dead clear on "we have to go full on rebranding", the
fact of life is that such huge efforts more often than not simply fail and
eventually 0% of the goal is achieved.

At the end we can deliberate a lot and have opinions, but if we can do
something "faster" that gets us into the right direction, and if we can
rather quickly verify the direction (and maybe running some verification,
polls, reaching out after that to see if we achieved something).

As much as I am fully for "disagree but engage" (my version of the saying),
I am all for experimenting and trying to fix things incrementally (and
seeing effect of it on the way) rather than venturing in to decades long
effort when we do not even know if it's needed and whether maybe 90% of the
effect can be achieved with 10% of the effort and time. I think
"achievability" is a very important aspect of this discussion and I'd only
appeal to the reason of people doing it (maybe including myself at some
time) to be aware that going "full rebranding" is not the only option, and
if the goal is to improve things, it might fail at "0%" stage if it is the
only option considered.

J.

On Wed, May 4, 2022 at 4:17 PM me  wrote:

> Bertrand, this is fantastic.
>
> I’m more than happy to assist w/ a strategy, approach, prep and board
> preso.
>
> Something that is worth mentioning up front is that whatever the outcome,
> there are going to be protractors and detractors. Unanimous support is
> challenging to achieve, and quite rare. Whatever the outcome, we have to be
> prepared to “disagree and commit” (i.e. support the majority even if the
> outcome isn’t specifically what we had hoped for).
>
> There are many possibilities from no change to wholesale rebranding (even
> some we haven’t thought of). The cool thing about change is that as long as
> we remain open to it, changes today don’t stop us from making more changes
> tomorrow!
>
>
>
> From: Bertrand Delacretaz 
> Reply: dev@community.apache.org 
> Date: May 4, 2022 at 05:10:53
> To: dev 
> Cc: Andrew Musselman 
> Subject:  Re: It’s time to change the name
>
> Hi,
>
> (Bcc people who have been active in the wiki page mentioned below)
>
> Le ven. 29 avr. 2022 à 16:14, Andrew Musselman  a écrit
> :
> > ...Can I propose an outreach to some Apache tribe governments so we can
> open a
> > dialog with them directly, and start to understand what their official
> > experience of the ASF branding is?...
>
> I think that would be very useful, helping us hear from leaders who
> have standing in the cause.
>
> Note that this was discussed earlier at [1] which has an initial list
> of Apache Nations that could be contacted. Access restricted to ASF
> members as the page contains contact information.
>
> If a team of ASF members wants to make this happen, I'm willing to
> bring the topic to the Board and would support giving that team an
> official status to help them do that outreach.
>
> Next step would be for you and other interested Members to form a team
> and present their action plan to the Board.
>
> -Bertrand
>
> [1]
> https://cwiki.apache.org/confluence/display/ASFP/Outreach+to+the+Apache+Nations
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Jarek Potiuk]

Agree. Makes perfect sense Bertrand. The reason for members-notify@ is very
clearly stated in the minutes and it's not that :).

J.

On Wed, May 4, 2022 at 10:26 AM Bertrand Delacretaz 
wrote:

>  -Hi,
>
> Le mar. 3 mai 2022 à 19:31, Craig Russell  a écrit :
> > I could not find where we decided whether to use members@ or
> members-notify@ but I approved it.
> > If anyone objects to the mail list, we can have that discussion for next
> time
>
> I do object to using members-notify@ for those news, as that's outside of
> the scope defined at [1]. That list was created "for the limited purpose of
> sending formal notifications to the membership as a whole", because some
> members clearly expressed their objection to getting "too much email" from
> the ASF.
>
> Another objection has been raised on board@, let's discuss there.
>
> Going forward I suggest sending to members@ with a [NEWS] subject line
> header. And don't get me wrong, I like this initiative!
>
> -Bertrand
>
>
> [1]
>
> https://www.apache.org/foundation/records/minutes/2020/board_minutes_2020_05_20.txt
> - search for "members-notify"
>

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Jarek Potiuk]

Happy to take on July one (I have Airflow Summit last week of May so I
expect heavy down/recovery time right after).

On Tue, May 3, 2022 at 9:20 PM Josh Fischer  wrote:

> Yes, I will take point for the June newsletter.
>
>
> On Tue, May 3, 2022 at 2:08 PM Rich Bowen  wrote:
>
> > On Tue, 2022-05-03 at 12:47 -0500, Josh Fischer wrote:
> > > Yeah!  Next month let’s work on making the email cleaner.  Less is
> > > more
> > > :-).  I saw what was sent, it was still a bit much to parse through
> > > and
> > > understand.
> > >
> >
> > Thank you, Josh, for handling this. Are you willing to take point again
> > for June?
> >
> > --Rich
> >
> >
> > > On Tue, May 3, 2022 at 12:35 PM Sam Ruby 
> > > wrote:
> > >
> > > > On Tue, May 3, 2022 at 1:30 PM Craig Russell 
> > > > wrote:
> > > > >
> > > > > I could not find where we decided whether to use members@ or
> > > > members-notify@ but I approved it.
> > > >
> > > > As did I.  :-)
> > > >
> > > > > If anyone objects to the mail list, we can have that discussion
> > > > > for next
> > > > time.
> > > > >
> > > > > Craig
> > > >
> > > > - Sam Ruby
> > > >
> > > > > > On May 3, 2022, at 10:16 AM, Josh Fischer 
> > > > > > wrote:
> > > > > >
> > > > > > sent.
> > > > > >
> > > > > > On Tue, May 3, 2022 at 12:05 PM Jarek Potiuk 
> > > > > > wrote:
> > > > > >
> > > > > > > Good idea Rich. Converted all subjects to plain text,
> > > > > > > compressed them
> > > > so
> > > > > > > that they fit in three short bullet points (not too long
> > > > > > > paragraph,
> > > > still
> > > > > > > comprehensible) and added the link from Rich :)
> > > > > > >
> > > > > > >
> > > > > > > On Tue, May 3, 2022 at 6:12 PM Rich Bowen
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > On Tue, 2022-05-03 at 10:56 -0500, Josh Fischer wrote:
> > > > > > > > > Sam Ruby, suggested a plain text version for this round
> > > > > > > > > of the
> > > > email.
> > > > > > > > > I
> > > > > > > > > **think** markdown was sent out last time and it didn't
> > > > > > > > > look good,
> > > > > > > > > making
> > > > > > > > > it harder to read/ understand .
> > > > > > > > >
> > > > > > > > > If we can find a way to make all the links easy to read,
> > > > > > > > > let's do
> > > > it.
> > > > > > > > > If
> > > > > > > > > not, we might want to move them to an additional,
> > > > > > > > > external apache
> > > > > > > > > wiki link
> > > > > > > > > page and add a single link directing readers to the
> > > > > > > > > additional link
> > > > > > > > > page.
> > > > > > > > >
> > > > > > > >
> > > > > > > > https://lists.apache.org/list?memb...@apache.org:2022-4 is
> > > > > > > > a
> > > > possible
> > > > > > > > link to that, in that it lists all of the threads that were
> > > > > > > > active in
> > > > > > > > April.
> > > > > > > >
> > > > > > > > > > You mean the links to text ? We can do it of course but
> > > > > > > > > > I have a
> > > > > > > > > > feeling
> > > > > > > > > > that that defeats the purpose a bit because it allows
> > > > > > > > > > the readers
> > > > > > > > > > to jump
> > > > > > > > > > straight to the discussion :).
> > > > > > > > > > I updated it now to have bullet-points instead - and as
> > > > > > > > > > long as it
> > > > > > > > > > is not

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Jarek Potiuk]

+1

On Tue, May 3, 2022 at 7:47 PM Josh Fischer  wrote:

> Yeah!  Next month let’s work on making the email cleaner.  Less is more
> :-).  I saw what was sent, it was still a bit much to parse through and
> understand.
>
>
>
>
>
> On Tue, May 3, 2022 at 12:35 PM Sam Ruby  wrote:
>
> > On Tue, May 3, 2022 at 1:30 PM Craig Russell 
> wrote:
> > >
> > > I could not find where we decided whether to use members@ or
> > members-notify@ but I approved it.
> >
> > As did I.  :-)
> >
> > > If anyone objects to the mail list, we can have that discussion for
> next
> > time.
> > >
> > > Craig
> >
> > - Sam Ruby
> >
> > > > On May 3, 2022, at 10:16 AM, Josh Fischer 
> wrote:
> > > >
> > > > sent.
> > > >
> > > > On Tue, May 3, 2022 at 12:05 PM Jarek Potiuk 
> wrote:
> > > >
> > > >> Good idea Rich. Converted all subjects to plain text, compressed
> them
> > so
> > > >> that they fit in three short bullet points (not too long paragraph,
> > still
> > > >> comprehensible) and added the link from Rich :)
> > > >>
> > > >>
> > > >> On Tue, May 3, 2022 at 6:12 PM Rich Bowen 
> wrote:
> > > >>
> > > >>> On Tue, 2022-05-03 at 10:56 -0500, Josh Fischer wrote:
> > > >>>> Sam Ruby, suggested a plain text version for this round of the
> > email.
> > > >>>> I
> > > >>>> **think** markdown was sent out last time and it didn't look good,
> > > >>>> making
> > > >>>> it harder to read/ understand .
> > > >>>>
> > > >>>> If we can find a way to make all the links easy to read, let's do
> > it.
> > > >>>> If
> > > >>>> not, we might want to move them to an additional, external apache
> > > >>>> wiki link
> > > >>>> page and add a single link directing readers to the additional
> link
> > > >>>> page.
> > > >>>>
> > > >>>
> > > >>> https://lists.apache.org/list?memb...@apache.org:2022-4 is a
> > possible
> > > >>> link to that, in that it lists all of the threads that were active
> in
> > > >>> April.
> > > >>>
> > > >>>>> You mean the links to text ? We can do it of course but I have a
> > > >>>>> feeling
> > > >>>>> that that defeats the purpose a bit because it allows the readers
> > > >>>>> to jump
> > > >>>>> straight to the discussion :).
> > > >>>>> I updated it now to have bullet-points instead - and as long as
> it
> > > >>>>> is not
> > > >>>>> too long, that might be better visually.
> > > >>>>> But if you feel like we need to decrease the number of links, I
> am
> > > >>>>> ok with
> > > >>>>> removing the links as well.
> > > >>>>>
> > > >>>>> J.
> > > >>>>>
> > > >>>>>
> > > >>>>> On Tue, May 3, 2022 at 4:56 PM Josh Fischer  >
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Any way we can convert your addition to text?  I feel it may be
> a
> > > >>>>>> lot to
> > > >>>>>> sift through visually.
> > > >>>>>>
> > > >>>>>> On Tue, May 3, 2022 at 8:32 AM Jarek Potiuk 
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Updated. I think it's cool.
> > > >>>>>>> I limited it to only discussions started in April.
> > > >>>>>>>
> > > >>>>>>> Seems we have a small enough number of discussions starting
> > > >>>>>>> every
> > > >>>>> month,
> > > >>>>>> to
> > > >>>>>>> fit one small paragraph easily - and seeing just subjects of
> > > >>>>>>> the
> > > >>>>>>> discussions with links directly to the discussions might be a
> > > >>>>>>> nice
> > > >>>>>

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Jarek Potiuk]

Good idea Rich. Converted all subjects to plain text, compressed them so
that they fit in three short bullet points (not too long paragraph, still
comprehensible) and added the link from Rich :)


On Tue, May 3, 2022 at 6:12 PM Rich Bowen  wrote:

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

Re: Idea: Monthly Members Moment/Critical Committer Communications

[Jarek Potiuk]

You mean the links to text ? We can do it of course but I have a feeling
that that defeats the purpose a bit because it allows the readers to jump
straight to the discussion :).
I updated it now to have bullet-points instead - and as long as it is not
too long, that might be better visually.
But if you feel like we need to decrease the number of links, I am ok with
removing the links as well.

J.


On Tue, May 3, 2022 at 4:56 PM Josh Fischer  wrote:

> Any way we can convert your addition to text?  I feel it may be a lot to
> sift through visually.
>
> On Tue, May 3, 2022 at 8:32 AM Jarek Potiuk  wrote:
>
> > Updated. I think it's cool.
> > I limited it to only discussions started in April.
> >
> > Seems we have a small enough number of discussions starting every month,
> to
> > fit one small paragraph easily - and seeing just subjects of the
> > discussions with links directly to the discussions might be a nice
> > reminder/refresher/information for those who missed it.
> >
> > On Tue, May 3, 2022 at 3:18 PM Jarek Potiuk  wrote:
> >
> > > > One option is to put that digest on a separate page, and just
> provide a
> > > link to it?
> > >
> > > Or maybe simply put it in one paragraph/long line with links to
> relevant
> > > discussions :). I will try to do it and we can decide if it makes
> sense.
> > > Let me try.
> > >
> > > On Tue, May 3, 2022 at 2:44 PM Josh Fischer 
> wrote:
> > >
> > >> I plan on sending the newsletter in a few hours.  If someone wants to
> > add
> > >> anymore details please add them asap.
> > >>
> > >> On Tue, May 3, 2022 at 7:39 AM Rich Bowen  wrote:
> > >>
> > >> > On Tue, 2022-05-03 at 12:35 +0200, Jarek Potiuk wrote:
> > >> > > I looked through it - I have one other comment/proposal: should we
> > >> > > maybe
> > >> > > add a digest of discussions running on members@a.o ?  I think a
> lot
> > >> > > of
> > >> > > people does not follow up those and while it is easy to look at
> the
> > >> > > list in
> > >> > > archives, maybe listing the discussions with one-line summary
> would
> > >> > > be good
> > >> > > ?
> > >> > >
> > >> > > Happy to make such a digest if others agree it's a good idea.
> > >> >
> > >> >
> > >> > Yes, but ... I think it's very important that we don't make the
> email
> > >> > longer than one screen-full, as that will undermine the point here
> of
> > >> > it being only the most important things that every member MUST know.
> > >> >
> > >> > One option is to put that digest on a separate page, and just
> provide
> > a
> > >> > link to it?
> > >> >
> > >> >
> > >> >
> -
> > >> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > >> > For additional commands, e-mail: dev-h...@community.apache.org
> > >> >
> > >> > --
> > >> Sent from A Mobile Device
> > >>
> > >
> >
>