Re: [WG] Workgroups update

[Gary Gregory]

Thank you for following up.

How would I signal my interest in or join a working group? Maybe I missed
that part.

Gary

On Fri, Mar 29, 2024, 10:06 AM 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: "Maintainer" as an alias of PMC Member?

[Gary Gregory]

> There is nothing to solve here.

I couldn't agree more.

Gary

On Sun, Mar 24, 2024, 8:26 AM Rich Bowen  wrote:

> As much as folks love to debate names ... this isn't a real problem. Some l
> People call PMC members simply "PMC" and while this might grate on some
> people, it's not a real problem. It does not actually cause any bad
> outcomes other than the annoyance of a few people.
>
> There is nothing to solve here.
>
> Creating a new name will simply add yet more confusion and something else
> to get wrong.
>

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

[Gary Gregory]

On Sat, Mar 23, 2024 at 4:59 PM Christopher  wrote:
>
> Delegate implies designated authority/responsibility, more than
> "maintainer" or "member", I think. The PMC role is delegated by the
> ASF Board (usually lazily, upon notice by existing PMC members). So, I
> think the word technically works here, but I won't argue that it's
> that much better than "PMC member", but I'll point out that "member"
> on its own has similar questions: member of what?

Uh? Member of the PMC!

Gary

The main argument
> I'll make is that we don't use the word delegate in any other context,
> so it's less likely to cause confusion.
>
> Others to consider might be: associate (PMC-A) or representative (PMC
> Rep, or PMC-R).
>
> I thought "maintainer" was okay, because it implies some
> responsibility for the project... rather than merely somebody who
> occasionally contributes. But the wording is a bit confusing, because
> you're not exactly a "PMC maintainer" or "somebody who maintains the
> PMC". A maintainer would maintain the project, not the PMC for the
> project. So, it's more accurate to say a "PMC member" is a " name> maintainer". So, it doesn't quite work to replace the word
> "member", which I think is part of the goal.
>
> Personally, I'm not particularly fond of any of these... I don't have
> a problem using the more explicit "PMC Member" either...  but these
> are suggestions that might work if somebody were to really champion
> one of them to help reduce confusion for non-native English speakers,
> or anybody who tends to prefer nominative uses of language over
> descriptive uses and needs an unambiguous shortname.
>
> On Sat, Mar 23, 2024 at 4:34 PM Gary Gregory  wrote:
> >
> > Delegate from what to what?
> >
> > "member" is fine IMO.
> >
> > Gary
> >
> > On Sat, Mar 23, 2024, 4:14 PM Christopher  wrote:
> >
> > > Delegate?
> > >
> > > On Sat, Mar 23, 2024 at 3:42 PM Gary Gregory 
> > > wrote:
> > > >
> > > > I don't like "maintainer" here, a PMC member has a LOT more
> > > > responsibility than the name implies IMO.
> > > >
> > > > "Maintainer" and "Contributor" feel almost interchangeable where a
> > > > contributor might be a one-off and a maintainer more active. But we're
> > > > splitting hair here IMO.
> > > >
> > > > Gary
> > > >
> > > > On Sat, Mar 23, 2024 at 3:17 PM Craig Russell 
> > > wrote:
> > > > >
> > > > > I totally get the problem. I think if we can find a suitable title for
> > > PMC Member we could socialize it in a few years. Should have done this
> > > years ago.
> > > > >
> > > > > But "Maintainer" does not do it for me. Keep looking...
> > > > >
> > > > > Craig
> > > > >
> > > > > > On Mar 23, 2024, at 01:47, tison  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Random thought.
> > > > > >
> > > > > > You may find people not a native English speaker keep calling a PMC
> > > Member
> > > > > > of Apache Foo "Foo PMC".
> > > > > >
> > > > > > We correct it so many times and spread the knowledge on list. But
> > > the trend
> > > > > > I observed doesn't change and IMO it's hopeless to change.
> > > > > >
> > > > > > Since people tend to use a short ref and "committer" gives a 
> > > > > > one-word
> > > > > > identifier first image, I'm trying to propose officially alias "PMC
> > > Member"
> > > > > > as "Maintainer" so that our wording is aligned.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Best,
> > > > > > tison.
> > > > >
> > > > > Craig L Russell
> > > > > c...@apache.org
> > > > >
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > >
> > > >
> > > > -
> > > > 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: "Maintainer" as an alias of PMC Member?

[Gary Gregory]

Delegate from what to what?

"member" is fine IMO.

Gary

On Sat, Mar 23, 2024, 4:14 PM Christopher  wrote:

> Delegate?
>
> On Sat, Mar 23, 2024 at 3:42 PM Gary Gregory 
> wrote:
> >
> > I don't like "maintainer" here, a PMC member has a LOT more
> > responsibility than the name implies IMO.
> >
> > "Maintainer" and "Contributor" feel almost interchangeable where a
> > contributor might be a one-off and a maintainer more active. But we're
> > splitting hair here IMO.
> >
> > Gary
> >
> > On Sat, Mar 23, 2024 at 3:17 PM Craig Russell 
> wrote:
> > >
> > > I totally get the problem. I think if we can find a suitable title for
> PMC Member we could socialize it in a few years. Should have done this
> years ago.
> > >
> > > But "Maintainer" does not do it for me. Keep looking...
> > >
> > > Craig
> > >
> > > > On Mar 23, 2024, at 01:47, tison  wrote:
> > > >
> > > > Hi,
> > > >
> > > > Random thought.
> > > >
> > > > You may find people not a native English speaker keep calling a PMC
> Member
> > > > of Apache Foo "Foo PMC".
> > > >
> > > > We correct it so many times and spread the knowledge on list. But
> the trend
> > > > I observed doesn't change and IMO it's hopeless to change.
> > > >
> > > > Since people tend to use a short ref and "committer" gives a one-word
> > > > identifier first image, I'm trying to propose officially alias "PMC
> Member"
> > > > as "Maintainer" so that our wording is aligned.
> > > >
> > > > What do you think?
> > > >
> > > > Best,
> > > > tison.
> > >
> > > Craig L Russell
> > > c...@apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> > -
> > 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: "Maintainer" as an alias of PMC Member?

[Gary Gregory]

I don't like "maintainer" here, a PMC member has a LOT more
responsibility than the name implies IMO.

"Maintainer" and "Contributor" feel almost interchangeable where a
contributor might be a one-off and a maintainer more active. But we're
splitting hair here IMO.

Gary

On Sat, Mar 23, 2024 at 3:17 PM Craig Russell  wrote:
>
> I totally get the problem. I think if we can find a suitable title for PMC 
> Member we could socialize it in a few years. Should have done this years ago.
>
> But "Maintainer" does not do it for me. Keep looking...
>
> Craig
>
> > On Mar 23, 2024, at 01:47, tison  wrote:
> >
> > Hi,
> >
> > Random thought.
> >
> > You may find people not a native English speaker keep calling a PMC Member
> > of Apache Foo "Foo PMC".
> >
> > We correct it so many times and spread the knowledge on list. But the trend
> > I observed doesn't change and IMO it's hopeless to change.
> >
> > Since people tend to use a short ref and "committer" gives a one-word
> > identifier first image, I'm trying to propose officially alias "PMC Member"
> > as "Maintainer" so that our wording is aligned.
> >
> > What do you think?
> >
> > Best,
> > tison.
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: [WG: Badging] Tooling, reclaiming thread

[Gary Gregory]

I don't think we should allow IDs to be "reserved": Imagine you've
been granted committer privileges but you can't pick the ID you want
because it has been "reserved" by a non-committer, it seems backward.

Gary

On Wed, Mar 20, 2024 at 8:37 AM Paulo Motta  wrote:
>
> This is right Claude. Essentially, the people.apache.org handle can be seen
> as a “handle reservation” to a future ASF ID handle, that will be granted
> when the contributor becomes a committee.
>
> So it’s basically a pre-ASF ID handle granted to contributors without any
> privileges or login (except the people.apache.org auto-generated
> contributor page).
>
> On Wed, 20 Mar 2024 at 09:19 Claude Warren  wrote:
>
> > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta  wrote:
> >
> > >
> > > 3. John Doe fills a simple form and selects the username "doejohn", which
> > > is not an ASF id, but just a handle to a people.apache.org page. If an
> > ASF
> > > id exists with the same name, then the request is rejected.
> > > 6. After some years of contributions, John Doe is invited to be a
> > committer
> > > of Apache Foo.
> > >   a. John can "convert" its username "doejohn" into an ASF ID, or can
> > > choose another ASF ID handle when becoming a committer.
> > >   b. This kicks-off an update to people.apache.org/~doejohn to change
> > the
> > > role from "ASF Contributor" to "Committer at Apache Foo"
> > >
> > >
> > The above 2 points indicate that our new committer registration would
> > require that no handles used on people.apache.org be granted as an ASF id.
> > Seems like we need a way to track the union of ASF Id and
> > people.apache.org
> > handles.
> >
> >
> > --
> > 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

Re: [WG: Badging] Tooling

[Gary Gregory]

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 want to adopt it.
>
> > We should also have a simple way for people to propose new badges. Spot
> noted that the bottleneck with Fedora Badges has always been the design of
> the badge, not the lack of ideas.
>
> I agree but I think this may distract the initial implementation of the
> program. I think we should focus on one or a handful of carefully thought
> badges to start, and if they're proven effective then we could create a
> process to onboard new badges in the next iteration of the program.
>
> On Fri, Mar 8, 2024 at 11:21 PM Paulo Motta  wrote:
>
> > Nice discussion! A few comments:
> >
> > > I do not think that we need projects to opt in to this. Badges are not
> > aimed at projects. They are aimed at *people*.
> >
> > Disagree. Projects should have the autonomy to decide if they want to
> > adopt the ASF badging system for their contributions. I do not see why a
> > project would opt-out, but if they want to they should have this
> > prerrogative.
> >
> > > I am worried about gamification and a flood of PRs just to get badges.
> >
> > What’s the worry? A flood of PRs seems like a good thing for projects
> > needing contributions. 😊
> >
> > > Some people may not want badges; they should not be forced to have them
> > if they happen to meet the criteria.
> >
> > Badges need to be accepted by the awardee before being emitted.
> >
> > > Personally, I do not see the point of them.
> >
> > You are probably not the target audience for badges if you are a seasoned
> > contributor.
> >
> > > I wonder if there are there any privacy issue we should be able to
> > foresee?
> >
> > priv...@apache.org should determine if the privacy policy of the chosen
> > badging provider is acceptable, Badging WG members should not worry about
> > this.
> > On Fri, 8 Mar 2024 at 12:38 Gary Gregory  wrote:
> >
> >> Hi Rich,
> >>
> >> I don't have specific realistic concerns, I am trying to look ahead and
> >> avoid a "how didn't yiu guys think of THIS!" moment 😀
> >>
> >> Gary
> >>
> >> On Fri, Mar 8, 2024, 12:19 PM Rich Bowen  wrote:
> >>
> >> > > On Mar 8, 2024, at 12:09 PM, Gary D. Gregory 
> >> > wrote:
> >> > >
> >> > > Sure, badging can be fun and it sure seems popular on GitHub: I do
> >> like
> >> > my Mars 2020 Helicopter Mission badge (
> https://github.com/garydgregory/)
> >> !
> >> > >
> >> > > I wonder if there are there any privacy issue we should be able to
> >> &

Re: [WG: Badging] Tooling

[Gary Gregory]

> If number of PRs is to be used as a credit towards getting a badge,
maybe there should be a way to flag some PRs as undeserving.

Agreed and perhaps the same for commits and Jira tickets but that's the
last thing I want to spend time adjucating :-(

Gary

On Sat, Mar 9, 2024, 7:34 AM sebb  wrote:

> Badges may well cause some people to feel valued, but I think they can
> be divisive.
> What about people who don't 'earn' enough points to merit a badge?
> Might that not cause them to feel undervalued?
>
> The value of a person to an ASF project cannot be purely measured in
> terms of the number of contributions; the quality of those
> contributions is important.
>
> Regarding encouraging PRs: it's not the number of PRs that matter,
> it's the usefulness.
> If number of PRs is to be used as a credit towards getting a badge,
> maybe there should be a way to flag some PRs as undeserving.
>
> On Sat, 9 Mar 2024 at 12:17, 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 want to adopt it.
> >
> > > We should also have a simple way for people to propose new badges. Spot
> > noted that the bottleneck with Fedora Badges has always been the design
> of
> > the badge, not the lack of ideas.
> >
> > I agree but I think this may distract the initial implementation of the
> > program. I think we should focus on one or a handful of carefully thought
> > badges to start, and if they're proven effective then we could create a
> > process to onboard new badges in the next iteration of the program.
> >
> > On Fri, Mar 8, 2024 at 11:21 PM Paulo Motta  wrote:
> >
> > > Nice discussion! A few comments:
> > >
> > > > I do not think that we need projects to opt in to this. Badges are
> not
> > > aimed at projects. They are aimed at *people*.
> > >
> > > Disagree. Projects should have the autonomy to decide if they want to
> > > adopt the ASF badging system for their contributions. I do not see why
> a
> > > project would opt-out, but if they want to they should have this
> > > prerrogative.
> > >
> > > > I am worried about gamification and a flood of PRs just to get
> badges.
> > >
> > > What’s the worry? A flood of PRs seems like a good thing for projects
> > > needing contributions. 😊
> > >
> > > > Some people may not want badges; they should not be forced to have
> them
> > > if they happen to meet the criteria.
> > >
> > > Badges need to be accepted by the awardee before being emitted.
> > >
> > > > Personally, I do not see the point of them.
> > >
> > > You are probably not the target audience for badges if you are a
> seasoned
> > > contributor.
> > >
> > > > I wonder if there are there any privacy issue we should be able to
> > > foresee?
> > >
> > > priv...@apache.org should determine if the privacy policy of the
> chosen
> > > badging provider is acceptable, Badging WG members 

Re: [WG: Badging] Tooling

[Gary Gregory]

Hi Rich,

I don't have specific realistic concerns, I am trying to look ahead and
avoid a "how didn't yiu guys think of THIS!" moment 😀

Gary

On Fri, Mar 8, 2024, 12:19 PM Rich Bowen  wrote:

> > On Mar 8, 2024, at 12:09 PM, Gary D. Gregory 
> wrote:
> >
> > Sure, badging can be fun and it sure seems popular on GitHub: I do like
> my Mars 2020 Helicopter Mission badge (https://github.com/garydgregory/) !
> >
> > I wonder if there are there any privacy issue we should be able to
> foresee?
> >
> > I would guess that badges would be derived from data that a member from
> the internet public might be able to painstakingly assemble, but maybe not.
> >
>
> Every badge that I’ve come up with in brainstorming about this has been
> either 1) based on public information or 2) something that the recipient
> requests (like “I attended a particular event.”). None of it seemed
> particularly painstaking. Do you have concerns?
>
>
> > Should a person be allowed to opt out of a specific badge or the whole
> badge system?
>
>
> As I said in the email you responded to …
>
> >>
> >> For every badge system I’ve looked at, nobody receives any badges until
> they log into the system, creating their account. That is, these systems
> are all opt-in by default. If people are actual averse to receiving
> congratulations for their activities, then don’t create a badge system
> account. Done and done.
> >>
>
> Whether a person can opt out of a particular badge, that’s more a tooling
> question. I would assume that the answer is “yes” since this is just data,
> and data can be deleted.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [WG: Sharpeners] Propose: milder name

[Gary Gregory]

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

Re: [WG: Sharpeners] Propose: milder name

[Gary Gregory]

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.

2c,
Gary

On Sun, Feb 18, 2024 at 12:33 PM Rich Bowen  wrote:
>
> I'm not tied to either the name or the alliteration. I thought it was cute.
> I honestly don't see the antagonistic overtones, but I'll take your word
> for it.
>
> I also don't relish the naming debate. I suppose every name has
> implications for someone.
>
> I'll defer to whatever folks want to call it. Although with all of the
> caveats and objections I'm starting to wonder if anyone see the value in
> this that I do.
>
> Rich
>
> On Sat, Feb 17, 2024, 19:13 sebb  wrote:
>
> > Sorry, but I find the name 'Sharpeners' antagonistic and aggressive.
> > To me it sounds like a group gearing up for a fight.
> >
> > Having names that are alliterative is all very well, but I don't think
> > it should be at the expense of a name that has negative connotations.
> >
> > I am wary of starting a bike shed argument, but the current name is
> > not appropriate in my view.
> >
> > I wonder if Shapers would do?
> > Just a suggestion.
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >

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

Re: reporter.a.o 502 Proy error

[Gary Gregory]

For me it says "Loading base data" and that's it.

Gary

On Sun, Dec 31, 2023, 5:24 AM Daniel Sahlberg 
wrote:

> Hi,
>
> https://reporter.apache.org says "Notification [object Response]" after a
> timeout.
>
> It seems to be a call to https://reporter.apache.org/api/overview
> returning
> a 502 Proxy error
>
> Kind regards,
> Daniel Sahlberg
> (Serf and Subversion PMC)
>

Re: Problems with board reporter wizard?

[Gary Gregory]

I ran into this issue as well.

Gary

On Mon, Oct 30, 2023, 4:34 PM Daniel Sahlberg  wrote:

> Hi
>
> I have problems with the Board Reporter Wizard (
> https://reporter.apache.org/wizard/).
>
> I get an authentication prompt (basic auth, I think it is called..),
> authenticate with my apache id/password and then I get an error message:
> "Notification --- [object Response]".
>
> I've tried a new tab in incognito mode, rebooted, I even reinstalled my
> computer (ok, not only for this reason).
>
> It seems https://reporter.apache.org/api/overview is returning a 503.
>
> I'm chair for Serf and PMC in Subversion, think I used the wizard about a
> week ago drafting a report for Serf.
>
> Kind regards,
> Daniel Sahlberg
>

Re: Centralise DOAPs?

[Gary Gregory]

Please don't embed in HTML, this is Metadata that should be easily
consumable by external tools IMO.

Gary

On Fri, Sep 8, 2023, 6:28 AM Christopher  wrote:

> I think many projects already have their doap files on their website, do
> that's not really improving anything. It doesn't make much difference
> editing the fields embedded in HTML or in its own separate file.
>
> On Fri, Sep 8, 2023, 05:41 Bertrand Delacretaz 
> wrote:
>
> > Hi,
> >
> > On Fri, Sep 8, 2023 at 12:26 AM sebb  wrote:
> > > ...I think it would be worth considering setting up a central store for
> > DOAPs...
> >
> > As we require our projects to have a website anyway, wouldn't it be
> > better to get that information from the project's homepage instead of
> > a separate file ?
> >
> > As you mention, I think it's only the fields that rarely change that
> > are actually useful: the project's description, a few useful URLs,
> > programming language, communications channel URLs, project category,
> > code repository and download URLs, that's probably all we need ?
> >
> > That info can be embedded in HTML, for example using  elements,
> > Open Graph [1] maybe, with some ASF-specific extensions such as
> > og:asf:category ?
> >
> > This would put the information in a natural place for projects to
> > maintain it, and Open Graph metadata has other benefits.
> >
> > OTOH this means writing a conversion layer that, starting from a list
> > of *.apache.org subdomain names, grabs that data and converts it to a
> > format that's useful for projects.a.o.
> >
> > Another option would be to embed the current DOAP format using a
> > 

Re: projects.a.o "maintainer" field

[Gary Gregory]

Listing the PMC seems reasonable when I think about external tools
consuming this information. We shouldn't assume knowledge of our default
process IMO.

Gary

On Thu, Sep 7, 2023, 1:13 PM  wrote:

> With some attention on projects.a.o at the moment, I'd like to raise
> the subject of the "maintainer" field in the DOAP files. That field
> doesn't make sense in ASF-style projects. The "maintainer" is always
> going to be the project's PMC.
>
> I came across a few DOAP files that listed an individual name in that
> field, and that's misleading, at best.
>
> I'd like to drop 'maintainer' from the DOAP creation form. Are there
> any objections to that?
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Valid languages for projects.apache.org

[Gary Gregory]

I agree with Sebb, MXML is an XML _vocabulary_.

Gary

On Thu, Sep 7, 2023, 9:55 AM sebb  wrote:

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

Re: Valid languages for projects.apache.org

[Gary Gregory]

ODBC and JDBC are APIs, not languages, I hope we can all agree on that.

The "L" in XML and SQL stand for Language, so... ;-)

Gary


On Thu, Sep 7, 2023, 7:24 AM sebb  wrote:

> There are currently a few project DOAPs which use languages not in the
> current valid list.
>
> These are:
>
> BASH/Bash
> Freemarker
> Haxe
> JDBC
> ODBC
> SQL
> XML
>
> Whilst we could add Bash, we might then need to add all the other
> Shell languages.
> Freemarker is a templating language; could be added
> Haxe is a valid language; could perhaps be added
> JDBC and ODBC are not languages; I think they should be dropped from
> the classification.
> SQL and XML can perhaps be considered languages
>
> WDYT?
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: RFC: many PMCs have not provided DOAPs

[Gary Gregory]

I'm not I know what that entails.

Gary

On Tue, Sep 5, 2023, 10:26 AM  wrote:

> On Tue, 2023-09-05 at 09:55 -0400, Gary Gregory wrote:
> > > https://boxofclue.com/doap_projects.txt by sending each project a
> >
> > Eat own dog food ;-) https://paste.apache.org/
>
> Just to be clear ... are you volunteering to help with this outreach?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: RFC: many PMCs have not provided DOAPs

[Gary Gregory]

> https://boxofclue.com/doap_projects.txt by sending each project a

Eat own dog food ;-) https://paste.apache.org/

Gary

On Tue, Sep 5, 2023 at 9:03 AM  wrote:
>
> Hey, ComDev folks,
>
> Sebb sent the below to board@ earlier today, and I took it upon myself
> to ping some of these projects, in the hopes that we can get better
> data about our projects.
>
> It's bugged me for a while how many of our projects have meaningless
> descriptions, and it's been on my list for a long time to go around and
> encourage/help these projects to write better descriptions, so that
> beginners can have some notion of what they are looking at.
>
> Sebb's email looks like a really great place to start.
>
> So, I'm working through this list:
> https://boxofclue.com/doap_projects.txt by sending each project a
> reminder of the process, and the reasons it matters (See
> https://hackmd.io/AtAuQ60JRbWcH8-OsCHccQ for my template). I am not
> planning to do all of these at once, so if someone else wanted to pick
> up at some other point in the list and work through, that would be fine
> - just report back so we don't gang up on any PMC.
>
> *Hopefuly* we'll either start seeing some new DOAP files, or we'll see
> some feedback here on this list about problems encountered.
>
> Thanks, again, Sebb, for your attention to detail.
>
> --Rich
>
>
> On Tue, 2023-09-05 at 00:19 +0100, sebb wrote:
> > I've done a check of the PMCs that have no active DOAPs, as listed by
> > projects.apache.org.
> >
> > There are 59 of them [1], which is about 28% of the total.
> >
> > That means a lot of ASF PMCs are not fully represented in the project
> > listings.
> >
> > The DOAPs provide various useful data about ASF projects, and the
> > project listings may help PMCs attract contributors who are looking
> > for a project to support, so it is a shame that a large proportion of
> > PMCs are not represented.
> >
> > Maybe it would be a good idea to remind these PMCs that DOAPs can be
> > helpful to the health of their project?
> >
> > There is a guide [2] for creating DOAPs.
> >
> > Sebb
> > [1] Search the page
> > https://projects.apache.org/projects.html?committee for the string
> > '(0)'
> > [2] https://projects.apache.org/create.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[Gary Gregory]

I can't tell the difference between

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

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

Gary

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

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

Re: Changing the defaults for GitHub generated email titles?

[Gary Gregory]

I'm OK with a vote, make sure you explain what -1 means in this context
(count vs veto)


TY!
Gary

On Thu, Jul 27, 2023, 3:46 PM Christofer Dutz 
wrote:

> Ok,
>
> so after the discussion didn’t come up with any objections. I prepared a
> PR and that was merged today.
> Now the templates no longer have to have a mandatory “repository” variable
> ;-)
>
> I updated the PLC4X settings and it seems to be working nicely.
>
> So … where are we on this discussion?
> I would still like to change the defaults to the patterns I suggested
> (including the repository).
>
> What’s your thoughts? Should I simply start a vote?
>
> Chris
>
>
>
> Von: Christofer Dutz 
> Datum: Mittwoch, 19. Juli 2023 um 14:35
> An: dev@community.apache.org 
> Betreff: AW: Changing the defaults for GitHub generated email titles?
> Hi all,
>
> So, I’ve tracked down the requirement to the test, that requires the
> “repository” variable,
> But it doesn’t really explain why it’s required. I was told that it’s for
> some 20 year old reason, however that simply can’t apply to the custom
> email templates for GitHub ;-)
>
> So, I opened a discussion thread
> https://lists.apache.org/thread/wz6f71wovzsz0nk6bdpgs8m17f07o2ko
> Feel free to add your comments to it.
>
> Chris
>
>
> Von: Christofer Dutz 
> Datum: Dienstag, 11. Juli 2023 um 16:29
> An: dev@community.apache.org 
> Betreff: AW: Changing the defaults for GitHub generated email titles?
> I have absolutely no idea … just whenever you leave it away the system
> starts yelling at you, telling you that it’s required ;-)
> If the computer says so … I gotta obey ;-)
>
> Von: Kelly Oglesbee 
> Datum: Dienstag, 11. Juli 2023 um 15:00
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> Why id this necessary?
>
> On Tue, Jul 11, 2023, 8:56 AM Christofer Dutz 
> wrote:
>
> > Hi Phil,
> >
> > Well, you can somewhat reduce it to whatever you like … however there
> > seems to be one limitation, which I can’t quite explain.
> > For some reason you need to have the repository name as part of the
> > subject line. That’s why I added it to the end as there it didn’t
> interrupt
> > my speed-reading and didn’t show up on my phone.
> >
> > And yeah … I agree that I also prefer the super-minimal prefixes [PR] for
> > Pull-Requests [I] for Issues and [D] for Discussions.
> > I think it takes me something round half a second to know that it’s a PR,
> > Issue or Discussion.
> > Generally, I could even live without them all together as it doesn’t
> > really matter, if a discussion is about a PR, Issue or just a
> > general-purpose discussion.
> > In an all-email workflow, we never had these prefixes before … everything
> > was just a discussion.
> > But if you ask me .. I’d keep the minimal prefixes, but be in favor of
> the
> > smaller ones above [PULL-REQUEST], [ISSUE] and [DISCUSSION] …
> > well … I guess that was why I chose these defaults for the projects I
> > could change it ;-)
> >
> > Chris
> >
> >
> > Von: Phil Steitz 
> > Datum: Mittwoch, 5. Juli 2023 um 20:57
> > An: dev@community.apache.org 
> > Betreff: Re: Changing the defaults for GitHub generated email titles?
> > +1 from another Commons contributor drowning in the flood of cruft on
> > commons-dev.  Shorter subject lines would be great.  I don't know if the
> > tooling would support or can be customized for Commons, but one thing
> that
> > would help would be to uniformly drop the word "Commons", so we go back
> to
> > what we did when we actually used the dev list for discussion
> [Commons-Foo]
> > is just [Foo].  There is also no value in the [GitHub] prefix in the
> > messages from there.  All PRs come from there.  Probably should talk
> about
> > this on Commons-dev (maybe with some special decorations on the subject
> > line so people will see it amidst all of the bot stuff :)
> >
> > Phil
> >
> > On Mon, Jul 3, 2023 at 5:48 AM Gary Gregory 
> > wrote:
> >
> > > Thanks for sharing these links; what a great start :-)
> > >
> > > I'm pretty sure the Commons community will welcome these kinds of
> > > changes where a complaint has been the "flood" of emails from GitHub,
> > > so hopefully this will help.
> > >
> > > For my money though, I'd prefer much shorter subject prefixes, even to
> > > the extreme, I'll just learn the codes, otherwise, it's impossible to
> > > read on my phone, which would be counterproductive (fo

Re: Changing the defaults for GitHub generated email titles?

[Gary Gregory]

Thanks for sharing these links; what a great start :-)

I'm pretty sure the Commons community will welcome these kinds of
changes where a complaint has been the "flood" of emails from GitHub,
so hopefully this will help.

For my money though, I'd prefer much shorter subject prefixes, even to
the extreme, I'll just learn the codes, otherwise, it's impossible to
read on my phone, which would be counterproductive (for me).

For example, [BUILD-FAILURE] -> [BUILD-FAIL] -> [BUILD-F] -> [B-F],
just something much shorter, again, think phone. B means Build, F
means Fail, that kinda mapping. I'm not sure where the mapping would
be best documented, perhaps on each project's mailing list page.

Gary

On Mon, Jul 3, 2023 at 8:12 AM Christofer Dutz
 wrote:
>
> Hi all,
>
> So here’s an example of one week’s email traffic on one project before and 
> after the config changes:
>
> (Sorry for putting the Spotlight on you streampipes folks, but this is the 
> best positive example I know)
>
> Before the change:
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
> Here you can see, that:
> a) It’s hard to see what something is about as the prefix is very large
> b) The only grouping happening is the same person doing the same thing on one 
> issue (commenting on an issue for example)
>
> Also, one week on the same list, with updated settings:
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-6-12|dto=2023-6-18:
> Here you can see:
> a) Greatly reduced number of threads
> b) Threads are grouped together
> c) You can actually follow a thread
> (The reason so many threads start with “RE:” is that the initial post seems 
> to be outside of the date-range of that week and the reason for one or two 
> long discussion titles, was they changed the config on 16.06.2023)
>
> Hope this brings a bit more context for some.
>
> Chris
>
>
>
> Von: Shane Curcuru 
> Datum: Freitag, 30. Juni 2023 um 23:20
> An: dev@community.apache.org 
> Betreff: Re: Changing the defaults for GitHub generated email titles?
> Christofer Dutz wrote on 6/30/23 3:49 AM:
> ...snip...
> > So in general, I would like to change the defaults used by the GitHub 
> > tooling to the ones I proposed in 
> > https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> >  . Quite a number of projects have adopted these settings:
> > Like StreamPipes: 
> > https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M
>
> +1 to giving this several more days of review and refinement, and then
> holding a vote to make this a ComDev PMC recommendation of best practice
> and then working (separately) on how to announce and make any changes.
>
> A couple of things I'd love to see:
>
> - A clear example of a before and after within a single project.  Come
> up with a specific Ponymail date search URL that shows one week of
> old-style notifications on a dev@ list, and then a second URL that shows
> a week of new-style notifications from the same dev@ list.  Directly
> seeing that difference would really help cement "yes, let's do it!"
>
> - Changing Chris' description page above to clearly show the best
> practice first, and then talk about how to find options for projects
> that want to customize.  The page as written now is good at helping
> convince someone new that 1) this is an easy change, and 2) this is a
> good idea.
>
> When we work on communications to PMCs, we need a "How-To setup best
> practices for GH notifications" guide that focuses on the *why*
> "Inclusion and transparency", and then the *steps to do/configure* which
> would be brief description of asfyaml stuff, and start with the best
> practice configuration, explaining what it does.
>
> After that in the doc, include the original GH notifications and other
> pointers to technical reference.
>
> Thinking ahead, I'd be happy voting to send out PMCs email saying "the
> default notifications are going to change on date X; email here to
> opt-out".  Keep track of opt-outs, and then change defaults for all.
>
> --
> - Shane
>ComDev PMC
>The Apache Software Foundation
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org

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

Re: Changing the defaults for GitHub generated email titles?

[Gary Gregory]

I read a lot emails on my phone, so shorts subjects are good. If each
subject becomes [PROJECT][DISCUSSION][PR 123] then it's worse than now IMO.

Gary

On Fri, Jun 30, 2023, 04: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
> >
> >
>

Re: home.apache.org code migration

[Gary Gregory]

I do love me some GitHub mirror from GitBox but I wonder how we want to
keep some institutional Subversion knowledge within Apache by keeping some
repositories there. Maybe that's just a problem for svn to deal with of
course.

Gary


On Wed, Jun 28, 2023, 11:13 Gavin McDonald  wrote:

> Hi All,
>
> Currently the website source for home.apache.org lives in svn at :
>
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/home
>
> As part of closing down the 'projects' directory I would like to see
> this directory and its contents moved elsewhere. I was thinking Git/Github
> either in its own repository.
>
> Thoughts?
>
> Gav... (ASF Infra)
>
>
> -
> 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

[Gary Gregory]

If we adopt a badge system, I hope it can be automated (a la github),
because I don't want to spend time reading or voting on who gets what badge.

Gary

On Thu, Jun 22, 2023, 07:33 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: Community-run MVP programs at the ASF

[Gary Gregory]

A badge needs a place to put it and we aren't github where your profile
page displays badges. I don't think we want to invent profile pages for
Apache just to display badges. And your ~userid page is not the right place
for that I think since users could put up any kind of image. Badges are
fun, sure, but is that how we want to spend our energy?

Gary

Gary

On Thu, Jun 22, 2023, 05:23 Matthew O'Brien
 wrote:

> I have yet to contribute on the coding side of things as I am still
> learning, yet I agree with the above "badge" style system as being
> something that encourages active engagement and is still egalitarian in
> nature as it facilitates all contributors to remain equal (as opposed to
> the dichotomised system that results from the implementation of an "MVP"
> type option).
>
> I have recently returned to forums I have been a member of for close to
> two decades after getting disillusioned with the algorithmic gaming of
> mainstream modern social media, whereby a select few are promoted by the
> algorithm to the detriment of the rest of the userbase. And having seen
> such a system as the proposed "reward badges" in place to where my forum
> activity has resulted in attaining such rewards for participating, I can
> speak from experience that the incentive to contributors is a greater
> option than "picking favourites" as the MVP system does.
>
> The forum I speak of has seperate tiers for posters (committers for the
> ASF equivalent) and the badges for other noteworthy contributions which I
> am sure the Dev community here could devise something similar that would
> work.
>
> Hope this gives an insight from an end user perspective of similar systems.
>
> Cheers
>
> Matthew Luke O’Brien
>
>
> > On 22 Jun 2023, at 4:35 pm, Bertrand Delacretaz 
> wrote:
> >
> > On Thu, Jun 22, 2023 at 12:39 AM Phil Steitz 
> wrote:
> >> ...I strongly disagree with the idea of designating "MVPs" at any level
> in the
> >> ASF...
> >
> > Same here, I object to having "most valuable" titles in ASF projects,
> > as it can be understood to mean others are less valuable.
> >
> > It's probably a cultural thing, I know "most valuable something" is
> > common in the US and probably not understood as I do, but we have
> > multiple cultures here so we need to be careful. The ASF aims to be
> > *very* egalitarian, sometimes too much maybe, but that has served us
> > well on multiple occasions. To me, the goal should be to recognize
> > someone's achievements without implying that they are generally better
> > than others. Better at a single thing maybe, but nobody's perfect.
> >
> > I see MVP has been replaced by "Ambassador" in the Cassandra document,
> > that's better, but it still takes a single angle on someone's value,
> > for example requiring that someone "Maintains 1 year of active
> > experience in public speaking, organising events or publishing content
> > on the project's channels".
> >
> > Some people might not be willing or able to do these things, yet make
> > tremendous contributions to a project in other ways.
> >
> > I'd personally find a "fun badges" system better suited to rewarding
> > people's varied sets of skills and engagements, from a community point
> > of view that's orthogonal with ASF roles, ideally in a tongue-in-cheek
> > style that prevents the badges from being given too much value.
> > "Traveling Salesman", "Broken Tests Mechanic", "Memory Leaks Plumber"
> > are the types of badges that come to mind, and can be celebrated to
> > highlight someone's achievement without making that too serious.
> >
> > I'm commenting on this from an ASF-wide perspective, our projects are
> > of course free to do many of their own things as long as it doesn't
> > conflict with ASF values - but as the question was about "providing
> > guidance to ASF projects" I thought that's useful. And yes, IMO
> > providing such guidance definitely belongs to comdev, reminds me of
> > https://community.apache.org/committers/funding-disclaimer.html
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

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

[Gary Gregory]

Yes, one page please, with old links redirected to the one page.

2c,
Gary

On Tue, May 30, 2023, 15:45  wrote:

> We have four pages that discuss decision making, voting, consensus, and
> so on.
>
> https://community.apache.org/committers/consensusBuilding.html
>
> https://community.apache.org/committers/lazyConsensus.html
>
> https://community.apache.org/committers/decisionMaking.html
>
> https://community.apache.org/committers/voting.html
>
>
> I could possibly see this being either one page, or two (with the first
> three being one, and then voting being another?) but having four, with
> largely overlapping content, is confusing.
>
> I'd like to consolidate, but would like to hear opinions as to whether
> this is one page or two (or some other answer) before I get started.
>
> Still working on the last proposal, FYI, so this is still a ways out.
> Or, maybe someone else can tackle it?
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Would this be a best practice? How-to contribute.json

[Gary Gregory]

Would it be nice to have this in POM files for Maven projects?

Gary

On Tue, May 9, 2023, 13:23 Shane Curcuru  wrote:

> Mozilla has an interesting practice of having a contribute.json schema
> for their projects, which includes a brief description, the key
> technologies used in the project, and a structured set of links to key
> project resources / ways to contribute:
>
>https://www.contributejson.org/schema
>
> Given we have some energy lately on finding structured ways to help ASF
> projects better showcase themselves to newcomers, any interest in this?
>
> Unless the schema gets widely used outside Mozilla, I don't know that
> we'd want to copy this, but really finding a simple way to describe the
> key "where's the source for the website so I can fix a typo", etc. list
> of resources would be really nice.
>
> Or should we go all-in on our DOAP files, and add this kind of data,
> along with actually, y'know, updating the DOAP tooling?
>
> --
> - 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: Standardise on 'main' as the default branch?

[Gary Gregory]

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 
> > 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: [DISCUSS] ASF Mastodon instance?

[Gary Gregory]

Then why not just keep using Slack?

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 to have a
> clean
> >  account that can be used for project announcements (i.e. usable by
> > PMCs
> > >> ?)
> >  I expect this to also make it quite easy to archive all
> communication
> > >> via
> >  this route.
> >  Like:
> > 
> >  - @a...@apache.org
> >  - @fl...@apache.org
> > 
> >  Second (I consider this to be optional) it would allow all
> >  committers/pmcs/... to have a clean ASF relatable point of
> > >> communication.
> >  In my case
> > 
> >  - @nielsbas...@apache.org
> > 
> >  I have NO idea how easy/hard/expensive such a thing is at the scale
> of
> > >> the
> >  ASF.
> >  I just wanted to drop the idea here so it can be discussed (and then
> > >> either
> >  be accepted or rejected).
> > 
> >  Curious to hear your thoughts.
> > 
> >  --
> >  Best regards
> >  Niels Basjes
> > 
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>

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

[Gary Gregory]

Maybe this is a case of "Perfect is an enemy of good" -- Voltaire

Gary

On Fri, Mar 25, 2022, 11:04 Adeel  wrote:

> Strange why all this help for only ukraine?
>
> Why not also set up a help-yemen, help-afghanistan, help-libya, help-iraq,
> help-syria, help-palestine channels? Why the obvious bias? Are people from
> those regions not human?
>
> On Wed, 16 Mar 2022 at 11:28, Christofer Dutz 
> wrote:
>
> > Hi all,
> >
> > I just recently gave shelter to a group of 6 refugees from the Ukraine.
> > This group consists of:
> >
> >   *   One mother with two small children (2 and 5)
> >   *   The grandmother
> >   *   The "nanny" with her 10-year-old
> >
> > They have expressed wanting to get a job as soon as possible. As my
> > apartment is in Darmstadt, jobs would have to be either close to
> Darmstadt
> > or remote ones.
> >
> > The mother seems to have worked as a social media marketing professional
> > with photography (products and people) and speaks good English.
> > The "granny" isn't really close to a pensioner yet and got a degree in
> > Physics (Used to teach that) but worked in the logistics of a furniture
> > manufacturer. However, she only peaks a little English.
> > The "nanny" has a degree in Psychology and Psychiatry. However, she also
> > only peaks a little English and said she'd love to work as a nurse.
> >
> > Now I know this is not the mission of the ASF, but the ASF is also a huge
> > network of people knowing people and people knowing companies.
> > So, I thought, wouldn't it be nice to setup a "help-ukraine" slack
> channel
> > or something like that, where people willing to help can quickly
> exchange?
> > As soon as this whole thing is over (hopefully sooner than later) we can
> > just drop the channel again.
> >
> > What do you think about the channel ... and does anyone know any job
> > openings for these great people?
> >
> > Chris
> >
>

Re: SPDX identifiers in Apache projects

[Gary Gregory]

Or after?

Gary

On Sat, Mar 19, 2022, 09:10 Willem Jiang  wrote:

> According to the example of SPDX ID[1], if we want to adopt the  SPDX
> ID, we may need to add a comment line in the file header just like
> below
>
> // SPDX-License-Identifier: Apache-2.0
>
> I think we can add it before the License header of Apache.
>
> Just my 2 cents.
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Mar 19, 2022 at 8:12 PM kezhenxu94@apache 
> wrote:
> >
> > Both SPDX identifier (short form) and full boilerplate can be used to
> apply the Apache License. And because ASF has our own specific template
> that is related to our use of a CLA, so we required ASF projects to use
> this specific one[2].
> >
> > [1] https://www.apache.org/legal/src-headers.html#headers
> >
> > > On Mar 19, 2022, at 17:03, tison  wrote:
> > >
> > > Hi,
> > >
> > > Recently I notice the SPDX identifiers format defined by the Linux
> > > Foundation for machine
> > > processing of license information based on the SPDX License Identifiers
> > > that are here available:
> > > http://spdx.org/licenses/.
> > >
> > > I can see that all of Apache project use it's own License header
> > > template[1] and curious what's
> > > the suggestions on using SPDX identifiers in Apache projects. Can an
> Apache
> > > project adopts both
> > > conventions? Is it encouraged or acceptable a general project using
> Apache
> > > License using the
> > > SPDX identifiers as license header?
> > >
> > > Best,
> > > tison.
> > >
> > > [1]
> > >
> https://github.com/apache/skywalking-eyes/blob/eb0e0b091ea41213f712f622797e37526ca1e5d6/assets/header-templates/Apache-2.0-ASF.txt
> >
> > —
> > Zhenxu Ke (柯振旭)
> > GitHub @kezhenxu94
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

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

[Gary Gregory]

We just went through this with Log4j and decided that the Tidelift model
was not compatible with Apache. Hopefully someone on our PMC can provide a
recap.

Gary

On Sun, Feb 27, 2022, 17:06 Roman Shaposhnik  wrote:

> Hi!
>
> over the past couple of years there has been a number
> of efforts trying to figure out effective ways of getting funded
> for working on ASF projects as individuals and not employees
> at companies building on top of these projects.
>
> Chris's recent experience is but one of them:
> https://lists.apache.org/thread/momxgzzyq03lz54knvzhxm16r8j40vog
>
> My personal frustration with all these threads is that we never
> seem to arrive at any actionable suggestions for how developers
> like Chris can *easily* create these additional income streams.
>
> Rightfully, we at ASF basically say that it must be a 3d party issue
> to solve. It very much is. The problem is that doing so one one-off
> just perpetuates the logistical pain of setting up contracts, etc. etc.
> This creates a pretty significant barrier and, as Chris's experience
> would suggest it typically becomes too insurmountable for individual
> developers.
>
> Sure, there have been interesting attempts to "hack the system"
> and use things like GitCoin, BugMark and a few others to solve for
> this "how do we get back to our open source roots when individuals,
> not corporations were the economic agents around open source".
> But I honestly don't know of any of them becoming viable either.
> At least not so far.
>
> At the risk of tilting at windmills once again, I'd like to see if there's
> enough interest to take a crack at this problem yet again.
>
> And in the spirit of "hacking the system" I'd like to suggest that we
> focus on a 3d party solving it for us. In fact, I suggest we pick a
> very particular 3d party -- TideLift
>
>
> https://support.tidelift.com/hc/en-us/articles/4406293106324-Quickstart-guide
>
> Now, before you exclaim "who the heck appointed TideLift to solve it for
> us?"
> I'd be the first one to admit that I picked them because I know them
> really well and I do think they are the closest to giving us some of the
> answers.
> But above all, I'm suggesting we look at TideLift because they seem to
> be very much willing to work with us on actually changing their engagement
> model to fit our needs. IOW, it is not like their rules are cast in stone
> -- we can
> assume they are malleable. If anyone knows of a similar 3d party -- let's
> discuss
> that too.
>
> If, however, there's a general consensus about seriously looking
> at them as that 3d party -- I'd like to start collecting names of ASF
> developers (and PMCs) who would be willing to participate in
> a trial program with them of sorts and report back.
>
> If you have comments on anything above -- please reply in-thread.
>
> If you'd be interested in this trial -- you can either do that or just
> reply to me personally.
>
> Thanks,
> Roman.
>

Re: Thoughts on alternative communication channels for our communities

[Gary Gregory]

My assumption using Slack is that it is a convenience but that decisions
MUST be reflected on a mailing list.

Gary

On Wed, Feb 16, 2022, 08:13 Trevor Grant  wrote:

> I shared in Comdev channel on ASF Slack that on the mahout slack we have a
> convention that when we get to something that should be memorialized
> someone says, "This should really be reflected back to the list". And
> whoever says that has implicitly called "not it" for having to reflect it
> back- This motivates everyone to be the first to say "This should go back
> to the list". In the rare cases where no one says it- the original author
> reflects back to the list- as is the case with this email and the comdev
> list.
>
>
>
> On Wed, Feb 16, 2022 at 7:08 AM Gary Gregory 
> wrote:
>
> > Slack chat and video helped us tremendously on the Log4j team especially
> > since Log4Shell.
> >
> > Gary
> >
> > On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik  wrote:
> >
> > > Hi!
> > >
> > > while the classical ASF communication culture is pretty squarely
> > > centered around mailing lists it has become apparent in recent
> > > years that some of our communities (especially younger ones)
> > > prefer using alternative channels of communication. The range
> > > is pretty wide from Slack to Telegram and WeChat (and I have
> > > even heard of an occasional TikTok use ;-)).
> > >
> > > The question that originated from one of the board meetings and
> > > the one that I'd like to pose for this forum is basically: what's our
> > > collective advice to these communities on these alternative (and
> > > when I say alternative I really mean anything but a mailing list)
> > > communication channels?
> > >
> > > Personally I don't think denying them is a viable strategy, but I'd
> > > like to open up this discussion and see what others think.
> > >
> > > So... let's at least start with folks sharing their experience with
> > > these alternative communication channels: the good, the bad
> > > and the ugly.
> > >
> > > Personally, I don't think I have much to share -- I'm still very
> > > much a mailing list guy when it comes to ASF.
> > >
> > > Thanks,
> > > Roman.
> > >
> >
>

Re: Thoughts on alternative communication channels for our communities

[Gary Gregory]

Slack chat and video helped us tremendously on the Log4j team especially
since Log4Shell.

Gary

On Wed, Feb 16, 2022, 07:50 Roman Shaposhnik  wrote:

> Hi!
>
> while the classical ASF communication culture is pretty squarely
> centered around mailing lists it has become apparent in recent
> years that some of our communities (especially younger ones)
> prefer using alternative channels of communication. The range
> is pretty wide from Slack to Telegram and WeChat (and I have
> even heard of an occasional TikTok use ;-)).
>
> The question that originated from one of the board meetings and
> the one that I'd like to pose for this forum is basically: what's our
> collective advice to these communities on these alternative (and
> when I say alternative I really mean anything but a mailing list)
> communication channels?
>
> Personally I don't think denying them is a viable strategy, but I'd
> like to open up this discussion and see what others think.
>
> So... let's at least start with folks sharing their experience with
> these alternative communication channels: the good, the bad
> and the ugly.
>
> Personally, I don't think I have much to share -- I'm still very
> much a mailing list guy when it comes to ASF.
>
> Thanks,
> Roman.
>

Re: Tidelift

[Gary Gregory]

I agree that people should handle their affairs as they see fit RE Tidelift
but how should this be allowed to trickle in on Apache WRT mentions in web
sites and files like readme. IOW, should structs assets remove mentions of
Tidelift?

Gary

On Wed, Jan 12, 2022, 08:52 Jim Jagielski  wrote:

> IMO, the foundation and the project should do nothing associated with
> this. It should neither encourage or condone it. In no way should we enter
> into any agreement, contract, whatever, w/ Tidelift. If Tidelift wishes to
> work independently and directly w/ people, that's fine. But having the ASF
> and/or the project involved at any level should be disallowed.
>
> We cannot also ignore the obvious self-serving nature of the request by
> Tidelift and if we are comfortable with them using this as an opportunity
> for promotion.
>
> > On Jan 11, 2022, at 4:49 PM, Ralph Goers 
> wrote:
> >
> > Hello all,
> >
> > Recently the Logging Services PMC was approached by Tidelift offering to
> provide monetary support either to the project or individual committers. To
> obtain that sponsorship the project has to agree to the terms at
> https://support.tidelift.com/hc/en-us/articles/4406309657876-Lifter-agreement.
> It appears that Struts has accepted this already.
> >
> > 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 to evolve, so that's a conversation that I'm open to as we continue
> discussing :o)
> >
> > So it is clear to me that Tidelift requires the project as a whole to
> approve the agreement, even though only select individuals may choose to
> receive payment, especially since one of the requirements is a public
> acknowledgment of Tidelift on one of the project’s sites.
> >
> > I find this problematic as I cannot reconcile how it is OK for
> individuals to receive payment so that the ASF is not officially involved
> while at the same time the PMC must approve the agreement for individuals
> to be able to accept payment. Furthermore, I still have no idea whether the
> terms of the agreement would put a PMC in conflict with ASF policies or
> whether the ambiguities in the agreement would put the ASF in a bad place.
> I realize the ASF’s argument would be “We have nothing to do with this” but
> I suspect that wouldn’t fly since the PMC has to agree to it.
> >
> > To be clear, I have no idea if this is the correct place to discuss
> this. Personally, I was under the impression that a Legal Jira was where
> this kind of stuff got resolved. But here I am.
> >
> > Thoughts?
> >
> > Ralph
> >
> >
> >
> > -
> > 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
>
>

[ANNOUNCEMENT] Apache Commons Exec 1.2 Released

[Gary Gregory]

The Apache Commons Exec team is pleased to announce the 1.2 release!

Apache Commons Exec is a library to reliably execute external processes
from within the JVM.

This is a mostly a maintenance release after a long absence from new
releases and still requires a only minimum of Java 1.3.

Changes in this version include:

New features:

o Set names for started threads.  Issue: EXEC-55. Thanks to Dominik
Stadler.

Fixed Bugs:

o Issue: EXEC-68.
  Watchdog kills process immediately if timeout is too large.
  Thanks to Joel McCance.

o Issue: EXEC-57.
  Applied the patch from Nickolay Martinov but the timeout disguises the
fact that the process might be still running.
  Therefore added a sanity check in order to throw an exception if the the
timeout for join() was exceeded.
  Thanks to Nickolay Martinov.

o Issue: EXEC-60.
  Fixed dead lock by calling the timeout observers outside of the
synchronized block thereby removing on pre-requisite of a deadlock.
  Also added a test case to demonstrate that this problem is fixed (which
of course can not guarantee the absence of a dead lock).
  Thanks to Peter Kofler.

o Issue: EXEC-52.
  Tests fail on HP-UX, because it uses a different syntax for the ping
command.
  Thanks to Nickolay Martinov.

o Issue: EXEC-49.
  "Write dead end" IOException when using Piped streams w/PumpStreamHandler.
  When encountering a PipedOutputStream we will automatically close it to
avoid the exception.
  Thanks to Kevin Telford.

o Issue: EXEC-34.
  Race condition prevent watchdog working using ExecuteStreamHandler.
  Patch submittd by Kristian Rosenvold.
  Thanks to Marco Ferrante.

For complete information on Commons Exec, including instructions on how to
submit bug reports, patches, or suggestions for improvement, see the Apache
Commons Exec website:

Site: http://commons.apache.org/proper/commons-exec/

Download: http://commons.apache.org/exec/download_codec.cgi

Enjoy,
Gary Gregory on behalf of the Apache Commons Exec team

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory