Re: [C/C Europe 25] [DISCUSS] Where to hold the conference

[Rich Bowen]

> On May 17, 2024, at 3:49 AM, Claude Warren  wrote:
> 
> Who will be at CoC Bratislava?  Do we want to hold a BoF for CoC
> organizers?

Yes, but, I will caution you, these meetings are seldom productive. Having 20 
people sit around and say the names of their favorite city is not actually a 
good use of time. I would encourage you to have a specific agenda, and action 
items. Selecting a city is *mostly* a financial decision, and requires someone 
to collect actual proposals and compare them, not just list nice places to 
visit.

Yes, I am being cynical here. It’s because I have endured 20 years of these 
meetings, and half of them devolved into shouting matches (no, I’m not 
exaggerating. Ask Shane for his stories!) and the rest were just a waste of 
time.

I would encourage you, rather than having a “share our opinions” meeting, to 
delegate specific tasks, figure out a timeline for reporting and completion of 
those tasks, and then go get a beer. The nature of this work is that you can’t 
get it done in a meeting, and attempting to do so generally leads to heightened 
emotions.

—Rich


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

[WG-Website] Calling attention to projects that Do Stuff Right

[Rich Bowen]

I wanted to draw attention to two projects that are doing amazing things, and 
make a note that we should encourage other projects to do the same.

Specifically:

Yesterday I came across DataFusion’s “how to become a committer” page - 
https://datafusion.apache.org/contributor-guide/governance.html - and I would 
like for us to encourage other projects to use this page as a template for 
documenting their own committer conventions.

Secondly, I came across Arrow’s developer onboarding guide - 
https://arrow.apache.org/docs/developers/overview.html - and would like for us 
to encourage projects to write up something similar for their sites.

These could perhaps go somewhere in https://community.apache.org/pmc/ 

— 
Rich Bowen
rbo...@rcbowen.com

Re: Apache Phoenix Community health metrics are not getting displayed

[Rich Bowen]

> On May 7, 2024, at 4:42 PM, rajeshb...@apache.org  
> wrote:
> 
> Hi
> 
> I am Apache Phoenix Chair and need to prepare a board report and for that
> requires the community health metrics which are not getting displayed at
> board report wizard statistics.
> 
> Only thing I could see is the dev mailing list metric, no information on
> other mailing lists, PR activity and new contributors added etc.
> 
> Community Health Metrics:Notable mailing list trends:
> d...@phoenix.apache.org had a 1% increase in traffic in the past quarter
> (690 emails compared to 683):
> 
> Could you please help me or provide the metrics which are a bit urgent.

Many thanks to Daniel for fixing the issue with the Kibble box, but ...

For whatever it's worth, the “community health metrics" are interesting, but 
hardly urgent. When the directors read the reports, they tend to be much more 
interested in your interpretation of how the community is ticking along, rather 
than a list of numbers. Many of the directors have consistently said this - 
numbers are merely data, while your narrative of the community health and 
sustainability is what we’re actually looking for when we read reports.

I might even go so far as to say that a lot of the directors simply skip over 
these statistics, because they don’t convey any actual information.

For example, when I look at your report, I see the list of numbers at the 
bottom, and I’m not sure what they mean. So, "Issue-related emails decreased by 
28% from 1664 to 1208” … does this mean that you’ve achieved better code (ie, 
fewer things to report) or does it mean that users are losing interest? Only 
someone involved in the project has a sense of that. The same kind of question 
applies to the other statistics that you’ve pasted into the report.
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: https://projects.apache.org/statistics.html

[Rich Bowen]

> On May 13, 2024, at 9:08 AM, Pierre Smits  wrote:
> 
> That is indeed a pity.
> 
> IMO, regular and consistent provision of statistical insights (BI, comes to
> mind) supporting the statements in the quarterly project report would help
> would help the reader of a o assess a project's health beyond the
> statements found there. If the foundation can provide insights in its
> annual report (see e.g. page 19-22 of
> https://apache.org/foundation/docs/FY2023AnnualReport.pdf), it should be
> able to provide similar insights per project on a quarterly basis.
> 
> But having such provision to be dependent on an individual volunteer (or on
> a 3rd party without commitment) is a risk. Often far greater than initially
> hoped for.
> 
> As for the underlying technologies: the ASF has access to that with
> products like Apache Superset, Apache Arrow and various data storage
> solutions.

Do you have experience with those projects? Are you volunteering to help make 
this happen?
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

[WG-Advisors] Short instructional videos

[Rich Bowen]

Hi, folks,


I had a thought, while boarding a flight this week, that *short* instructional 
videos, in the spirit of the Delta pre-flight boarding videos, would be a 
valuable educational asset as we attempt to be more proactive in educating our 
PMCs (and our communities in general) about how to work correctly in Apache 
projects.

I have several such videos in mind, but I’m starting small.

One of the topics that I’m interested in tackling is how, and perhaps as 
importantly, why, to vote on a release. This is obviously already covered by 
official policy - https://www.apache.org/legal/release-policy.html - but we all 
know how often people read the documentation. But a 2-minute video may get 
across a few important points.

It is my goal to have a script written in the next few weeks, so that at 
Community Over Code Bratislava I can capture most of the visuals, and the 
narration, that I need to produce the video. The initial script is here:

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

I’ve shared it for comment, and would appreciate comments and suggested edits.

Please note that this is NOT intended to be comprehensive. It is intended to 
communicate two or three simple points, and then point to the docs. If we 
attempt to make it comprehensive, all we will accomplish is that nobody will 
watch it.

FYI, this is all part of a larger effort - 
https://docs.google.com/document/d/1CjOvEu2P6nBraUH_YvIV6ri-5OD9I3huM4AlqxXZQmY/edit?usp=sharing
 - to be more proactive, rather than reactive (and scolding), about our rules. 
The rules exist for specific reasons, but the way that we overwhelmingly 
communicate them, as scolding when people fall short, has given us a terrible 
reputation as only caring about rules and checkboxes.

— 
Rich Bowen
rbo...@rcbowen.com

Re: [C/C Europe 25] [DISCUSS] Where to hold the conference

[Rich Bowen]

> On May 6, 2024, at 5:12 AM, Bertrand Delacretaz  
> wrote:
> 
> On Fri, May 3, 2024 at 7:37 AM Claude Warren  wrote:
>> ...if you have opinions and/or ideas please speak up...
> 
> I've been to several small/medium conferences in Berlin [1] in the
> last few years and it was always a great experience.
> 
> Easy to travel to, including by train, reasonable costs most of the
> time (except when the marathon or similar events happen maybe), and we
> have a number of ASF members there who might help with contacts or
> more.

We also have a great existing relationship with a producer - Plain Schwarz - 
who are based in Berlin. They did ApacheCon 2018 (I think?) and that was a 
great event.
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [C/C Europe 25] [DISCUSS] Where to hold the conference

[Rich Bowen]

London can be a hassle for non citizen EU residents to travel to, since
Brexit.

Meanwhile many of us are at least familiar with Brussels having gone there
for fosdem for a decade or more.

Rich

On Fri, May 3, 2024, 05:54 Claude Warren  wrote:

> Francois,
>
> Do you know of anyone on the ground in any of those cities?  It helps to
> have a local person in place.  Not discounting any suggestions just yet,
> only looking for more data.
>
> Claude
>
> On Fri, May 3, 2024 at 10:15 AM Francois Papon <
> francois.pa...@openobject.fr>
> wrote:
>
> > Hi,
> >
> > I think it would be nice to have the event at places like Bruxelles,
> > Paris, Barcelone, Berlin, London... and to see if we can talk with
> > others open source foundation to make a common event like JB mention.
> >
> > regards,
> >
> > François
> >
> > On 03/05/2024 07:36, Claude Warren wrote:
> > > There have been several volunteers to participate in the conference
> > > organizing committee so perhaps we should start by discussing where the
> > > conference should be held.
> > >
> > > Does anyone have any strong opinions or ideas?
> > >
> > > The 2024 committee considered the following factors when choosing the
> > > location:
> > >
> > > 1. Production cost (venue rental + services). 2024 was a reboot
> > (Community
> > > over Code is not positioned) so we are starting with sponsors from
> > > scratch.  2025 is is a slightly better place since the 2024 conference
> > made
> > > the European version of C/C visible to some sponsors and participants.
> > >
> > > 2. Easy to get to by either train or airport (giving priority to train,
> > > since we expect most attendees to come from EU and only a few from
> North
> > > America).
> > >
> > > 3. A city/area where it is easy to walk to nearby restaurants/bars so
> > that
> > > attendees would run into each other after conference hours.
> > >
> > > 4. A nice city that people would be interested in visiting, and
> probably
> > > never been to.
> > >
> > > So if you have opinions and/or ideas please speak up.
> > >
> > > Thanks,
> > >
> > > Claude
> > >
> > > p.s. We are still looking for a 2025 organizing committee chair.  Care
> to
> > > volunteer?
> > >
> >
> > -
> > 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
>

Re: Events calendar: help wanted

[Rich Bowen]

> On Apr 19, 2024, at 12:36 PM, sebb  wrote:
> 
> Before diving into any changes to how the calendar is defined and
> maintained, I think it is vital to establish what is wanted from the
> calendar, both from the maintenance point of view and the user PoV.
> 
> The existing calendar allows views by week, month and agenda (serial).
> One can move back and forth in the listings easily, and they can be
> downloaded and printed.
> Individual entries can be copied to one's personal calendar.
> Selecting an entry shows more information, with links to further details.
> There are probably more functions I have not considered.

Yes, that seems adequate.

FWIW, my minimum feature set is:

* Manage entries without having to edit ics files directly. (Details not 
terribly important, If I could interact with it via gui, that would be nice, 
but a simple text data format would be ok too.)
* Display events as a list (we already have this)
* Display events in a table-form calendar, so that overlaps/conflicts can be 
clearly seen. Bonus for displaying major world holidays.
* Ability to subscribe via standard calendar application.
* Entries can indicate a location and a URL for more detail

It sounds like you have all of that covered in your list.
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: Events calendar: help wanted

[Rich Bowen]

> On Apr 19, 2024, at 7:08 AM, Raphael Bircher  wrote:
> 
> The JavaScript Calendar will only need a .ics files

I would *really* like to not have to edit ics files directly. That way lies 
madness.

[jira] [Commented] (COMDEV-544) Improve comdev website navigation to GSoC mentor resources

[Rich Bowen (Jira)]

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

Rich Bowen commented on COMDEV-544:
---

FYI, that page is at 
[https://github.com/apache/comdev-site/blob/main/source/gsoc/_index.md] if you 
want to add such a section.

> Improve comdev website navigation to GSoC mentor resources
> --
>
> Key: COMDEV-544
> URL: https://issues.apache.org/jira/browse/COMDEV-544
> Project: Community Development
>  Issue Type: Task
>  Components: Website
>Reporter: Lewis John McGibbney
>Priority: Minor
>
> h1. Purpose
> Improve comdev website navigation to Google Summer of Code (GSoC) mentor 
> resources.
> h1. Context
> Having been ‘away’ for a few years, this year I decided to make an attempt to 
> re-engage with the GSoC program.
> I quickly realized that I was totally out of touch having absolutely no idea 
> where the mentor community conversations were happening (they happen on 
> ment...@community.apache.org) and being hopelessly unable to locate GSoC 
> mentoring documentation via the comdev website. 
> Thankfully [~sanyam] [pointed me at the 
> documentation|[https://lists.apache.org/thread/dqmrwzjogl3sdb2v8s36v8mxf5o1yqsj]]
>  and I was able to get back up to speed. Thank you Sanyam :)
> h1. Challenges
> Looking at [https://community.apache.org/gsoc/], as of writing, although 
> loads of content exists for students (which is great) no navigation exists to 
> mentor resources. 
> In my case, this meant that I couldn’t find and entirely missed the excellent 
> content available at [https://community.apache.org/mentoring]/.
> h1. Proposal
> I think that a “{*}Mentors: read this{*}” Section should be added to 
> [https://community.apache.org/gsoc/] which simply hyperlinks to the relevant 
> content from above. 



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

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

Re: Events calendar: help wanted

[Rich Bowen]

> On Apr 18, 2024, at 10:25 AM, Raphael Bircher  
> wrote:
> 
> Hi all
> 
> Just a notice: before we install an other tool only to have a Ical
> function... confluence already has a calendar.

Can you possibly say more about this, or perhaps provide a link?
-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: I am interested in contributing to the

[Rich Bowen]

Thank you for your interest in the Apache Software Foundation projects.

The ASF is home to more than 200 projects that span many topics,
programming languages, project sizes, code complexity, and other ways of
measuring. So where you get involved is going to vary based on your
interests.

* Projects by language: https://projects.apache.org/projects.html?language
* Projects by category: https://projects.apache.org/projects.html?category
* Projects by size: https://projects.apache.org/projects.html?number
* Projects by name: https://projects.apache.org/projects.html?name

Most ASF projects conduct much of their discussion on a mailing list.
These lists can be found at https://lists.apache.org/ where you can read
the recent, and historical, discussions around the project. This might
give you an idea of whether a particular project is a good fit for you.

Most of our projects have their source code on GitHub, where you can see
what the open issues are, review pull requests, or contribute changes.
https://github.com/apache/

If you are interested in working on community building, that's what the
Community Development (ComDev) project is about. Our work is divided
into various working groups, which are listed on our website at
https://community.apache.org/working-groups/

We're a big organization, with a lot of projects, so if any of this is
overwhelming, please to ask your followup questions here, and we'll try
to guide you towards where you can best fit in.

Welcome!

Rich, for Apache Community Development.


> On Apr 18, 2024, at 9:51 AM, paulo ambrocio  wrote:
> 
> is there any documentation or list of links so I can start contributing?
> 
> thanks,
> 
> Paulo

Re: Events calendar: help wanted

[Rich Bowen]

On Apr 17, 2024, at 12:33 PM, Raphael Bircher  wrote:
> 
> Hi Rich
> 
> The ICal from Google seems to work, so we could use a JavaScript wrapper to
> display it on the page. And if we want, we could replace the iCal Feed from
> Google to our own Doc food ;-)

To be clear, are you volunteering to do this work?


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

Re: Events calendar: help wanted

[Rich Bowen]

> On Apr 17, 2024, at 11:46 AM, sebb  wrote:
> 
> An obvious work-round is to provide a link to the calendar, rather
> than embedding it.
> 
> A link requires action by the user, so presumably counts as giving
> consent, (as long as the destination of the link is clear).


Sure. This also feels like a much worse user experience than having the 
calendar displayed on our own site.

Either way, someone needs to do this work.

Events calendar: help wanted

[Rich Bowen]

events.apache.org <http://events.apache.org/> is where we list upcoming events 
- both primary ASF events (Community Over Code) and project events (Pulsar 
Summit, eg) that have been approved by Trademarks and ComDev.

This site is backed by a Google Calendar, which is maintained by myself, Mark 
Thomas, and a handful of other people.

Due to changes in policy (I’m honestly completely unclear whether this is ASF 
policy, Google policy, or something else) the calendar page - 
https://events.apache.org/event/calendar.html - no longer works. There is a 
thread discussing this, and possible remediation, over on the 
plann...@apachecon.com <mailto:plann...@apachecon.com> list - 
https://lists.apache.org/thread/14v10tfbrjb50m21skl2mn1bgf6tj6go - but I’m 
really not sure how to proceed from here.

I see two possible solutions here:

1) We move the calendar to something that doesn’t involve a third-party 
provider. This strikes me as the best option - we own the data, and have some 
method of displaying that data that doesn’t rely on anyone else. There used to 
be a *ton* of open source calendaring solutions that we could host on our site. 
(I, myself, used to maintain a Perl CGI calendar called WebCal, way back in the 
late 1900s.) I would appreciate someone stepping up to find, evaluate, and 
recommend an option here that we can put into the events site.

2) Try to jump through the various hoops to get Google Cal working again. This 
does *not* feel like the right approach, to me, since it seems that we’d just 
be kicking the can down the road a while longer until yet another privacy 
policy bites us.

The events site is in Git here: https://github.com/apache/comdev-events-site

Is anyone available/willing to help with this work?

— 
Rich Bowen
rbo...@rcbowen.com

Re: [wg-socialmedia] Creating a BlueSky account?

[Rich Bowen]

Fwiw I'm in favor of being in every non-trivial social network if we have
people who will step up to

* Work with M to understand messaging
* Amplify official messages
* Engage with people on these platforms

Unfortunately the tools that allowed you to post to multiple platforms at
the same time have all been systematically broken by the platforms so this
will be daily/weekly manual work.

So ... do we have a group of volunteers to do this work?


Rich

On Sat, Apr 13, 2024, 12:18 Gláucia Esppenchutz 
wrote:

> Hi everyone,
>
> I would like to discuss with this WG about expanding our social media
> accounts to BlueSky.
> In the past months, BlueSky has (slowly) grown and attracted more
> people/companies to join.
> Here are some examples:
> https://bsky.app/profile/gizmodo.com
> https://bsky.app/profile/techcrunch.com
> https://bsky.app/profile/stanfordpress.bsky.social
> https://bsky.app/profile/uminnpress.bsky.social
>
> I am not saying we should abandon Twitter(X); I am just proposing expanding
> our social media and reaching more people.
> I also understand the cost (working time) of maintaining many platforms
> updated with Apache's news and posts. I would be happy to help!
> Just a thought, and I want to hear from you what you think about this
> topic.
>
> Cheers,
>

Re: possible booth at the DevBcnf 2024 June , 13-14.

[Rich Bowen]

> On Apr 4, 2024, at 7:28 PM, jean-frederic clere  wrote:
> 
> Hi,
> 
> We can get a table and 2 chairs for our booth at the DevBcn in Barcelona, 
> June 13-14.
> 
> Any interest?
> 
> I will be in Barcelona at that time, the agreement is the same as last year 
> and I can do the 50% presence at the booth.
> 
> Is it OK for me to sign the agreement as I signed it last year?
> 
> And who needs a copy of the agreement?
> 

Please make sure it makes it into source control somewhere at some point. 
Thanks.


> If we accept we get 2 tickets for the booth and 3 additional tickets for ASF 
> committers.

Re: New Joiner Msc Industrial Psychology

[Rich Bowen]

On Apr 2, 2024, at 1:30 PM, Ibrahim Mukherjee 
 wrote:
> 
> From: Ibrahim Mukherjee 
>> Date: 2 April 2024 at 18:23:45 BST
>> To: mailto:dev@community.apache.org
>> Subject: WG: New Joiner
>> 
>> Hi,
>> 
>> I am currently a PhD student interested in contributing to this group and 
>> Apache Foundation generally.
>> 
>> I have a MSc in Industrial Psychology.

Thank you for your interest in the Apache Software Foundation projects.

The ASF is home to more than 200 projects that span many topics,
programming languages, project sizes, code complexity, and other ways of
measuring. So where you get involved is going to vary based on your
interests.

* Projects by language: https://projects.apache.org/projects.html?language
* Projects by category: https://projects.apache.org/projects.html?category
* Projects by size: https://projects.apache.org/projects.html?number
* Projects by name: https://projects.apache.org/projects.html?name

Most ASF projects conduct much of their discussion on a mailing list.
These lists can be found at https://lists.apache.org/ where you can read
the recent, and historical, discussions around the project. This might
give you an idea of whether a particular project is a good fit for you.

Most of our projects have their source code on GitHub, where you can see
what the open issues are, review pull requests, or contribute changes.
https://github.com/apache/

If you are interested in working on community building, that's what the
Community Development (ComDev) project is about. Our work is divided
into various working groups, which are listed on our website at
https://community.apache.org/working-groups/

We're a big organization, with a lot of projects, so if any of this is
overwhelming, please to ask your followup questions here, and we'll try
to guide you towards where you can best fit in.

Welcome!

Rich, for Apache Community Development.


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

Re: Conflicting information about event promotion

[Rich Bowen]

I’ve fixed the doc on www-site with https://github.com/apache/www-site/pull/358

But ...


> On Apr 1, 2024, at 8:10 AM, Rich Bowen  wrote:
> 
> https://events.apache.org/README is almost completely wrong.
> 
> https://github.com/apache/comdev-events-site contains old information which 
> kind of works, but isn’t actively maintained, so will surely break at some 
> point.


Ok, now I’ve confused myself. The above two things (ie, specifically, README 
and README.md) should be the same resource, but they’re not, and I’m not sure 
why.

What am I missing?

Re: [PR] New Design for events.apache.org [comdev-events-site]

[Rich Bowen]

> On Apr 1, 2024, at 8:16 AM, RedYetiDev (via GitHub)  wrote:
> 
> 
> RedYetiDev commented on PR #12:
> URL: 
> https://github.com/apache/comdev-events-site/pull/12#issuecomment-2029669946
> 
>   Okay! Do you want me to split up this PR, or keep that in note for the 
> future?
> 
>   Thank you!


I like the design changes you’ve made, but the changes to the current event 
promotion stuff (that is, the /x/ removal, and the links to how to put an event 
promotion banner in your project website) are incorrect. (See my email 
“Conflicting information about event promotion”, which I’m currently working 
on.)

If you could drop that portion of the PR (ie, where you remove /x/ and the 
.htaccess file) we can address those problems separately. 

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

Conflicting information about event promotion

[Rich Bowen]

I was aware that there was some inconsistency in how we encourage people to 
promote Community Over Code, but RedYetiDev’s PR 
(https://github.com/apache/comdev-events-site/pull/12) for events.apache.org 
<http://events.apache.org/> has made me aware that there are numerous 
conflicting web pages regarding how to include event promotion in your project 
website.

First of all, this one is correct:

https://apachecon.com/event-images/


Then we have a variety of other ones, with varying correctness:

https://apache.org/ads/adserver.txt has correct information, and a variety of 
incorrect information.

https://events.apache.org/README is almost completely wrong.

https://github.com/apache/comdev-events-site contains old information which 
kind of works, but isn’t actively maintained, so will surely break at some 
point.

I’m putting this here in case someone gets to this faster than I do, and so I 
don’t forget.

— 
Rich Bowen
rbo...@rcbowen.com

Re: [PR] New Design for events.apache.org [comdev-events-site]

[Rich Bowen]

On Sat, Mar 30, 2024, 17:08 RedYetiDev (via GitHub)  wrote:

>
> RedYetiDev opened a new pull request, #12:
> URL: https://github.com/apache/comdev-events-site/pull/12
>
>In , the
> following item was listed: 'Keep this events.apache.org [website source
> code updated](https://svn.apache.org/repos/asf/concom/site/trunk/content).
> Possibly make it look better.', so I took on the task.
>
>This Pull-Request completely redesigns the website. It's hard to list
> all the changes, but I'll try
>## Technical
>- Remove `.htaccess` and update links directly
>- Remove `/x/`, as it always redirects to Community Over Code
>

No, it doesn't. This redirect is updated each time there's a different
active/current event.


   - Remove extra unused images
>- Make outgoing links target `_blank`
>- Update copyrights
>- Edit README.md for the newer site
>
>## Layouts + CSS
>- Replace the navbar with a expanding sidebar
>- Redo the CSS stylings in accordance with the changes to the website
>- Add a 404 page
>
>## Homepage
>- Remove event listing
>- Rewrite introduction + Table of Contents
>
>## Events
>- Replace 'past events' and 'upcoming events' with a calendar
>- Switch from native google calendar to fullcalendar
>- Retype introduction to calendar
>
>## About
>- Added 'The current version of this site was designed by [Aviv Keller
> (@RedYetiDev)](https://github.com/redyetidev)' to 'About This Website'
> (Credit where credit is due)
>- Replace 'apachecon' (404) link with 'Community Over Code'
>- Fix duplicated title in 'Endorsed Events'
>
>## Community For Code / ApacheCon
>- Fix invalid markdown
>- Reorganize list
>- Remove 'Possibly make it look better.' from volunteer opportunities
>- Fix incorrect twitter URLs
>
>## Getting Involved
>- Add subheaders to introduction
>- Redesign Mailing List Table
>
>## And so much more!
>
>## Screenshots
>![image](
> https://github.com/apache/comdev-events-site/assets/38299977/a0ae2c99-f580-43e9-a2de-7a083b549b12
> )
>![image](
> https://github.com/apache/comdev-events-site/assets/38299977/5042d0d3-554f-4e5c-ac79-dae7409c67e7
> )
>![image](
> https://github.com/apache/comdev-events-site/assets/38299977/e5a0720f-f041-466d-9df1-34076008ba3a
> )
>

Sweet. Thanks. I will try to have a look tomorrow.

>

Re: Board report wizard is not collecting statistics

[Rich Bowen]

On Sat, Mar 30, 2024, 21:06 Sheng Wu  wrote:

> Hi ComDev team
>
> I was working on writing SkyWalking board report, and wanted to check
> the community activity statistics, but I notice the board report
> wizard is not collecting statistics about GitHub relative things.
>
> - https://reporter.apache.org/wizard/statistics?skywalking
>
> You can see all GitHub activities have been missing since Jan 2024.
>

The reporter tool is maintained on a voluntary basis by the community
development committee and has not been very active recently. The full
details on how everything works are here
https://reporter.apache.org/about.html

I'm afraid I don't really know what to tell you other than anyone is
welcome to dig in and see if they can figure out what's broken.

Re: [WG] Workgroups update

[Rich Bowen]

On Fri, Mar 29, 2024, 21:14 Jarek Potiuk  wrote:

>
> * signing up to become an advisor:
>
> https://github.com/apache/comdev-working-groups/blob/main/wg-advisors/advisors.md
>

I know I'm not usually the one to raise this objection, but...

It occurs to me that some projects, and some individuals may not wish for
this info to be public. Is this a real concern? Should we move the list to
ASFP? It is it already optional?

Re: [WG] Workgroups update

[Rich Bowen]

> On Mar 29, 2024, at 1:17 PM, Jean-Baptiste Onofré  wrote:
> 
> Hi Rich,
> 
> That's great, thanks !
> 
> Quick question about wg-advisors: does this WG include "strong" advice
> to the PMC, like legal/trademark/brand advices to avoid issue ?
> 

Yes, we should definitely be giving this advice to projects, and linking to the 
official sources of those policies whenever possible.

This also came up in the context of Security issues - where we should be 
pointing to the Security team’s policy and advice when it’s relevant.

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

Re: Getting a project back on track

[Rich Bowen]

Thanks, folks.

I’ve opened a PR with the feedback from this thread - 
https://github.com/apache/comdev-site/pull/174 - and would appreciate a review, 
and if you think it passes muster, a merge. Thanks.

> On Mar 29, 2024, at 9:35 AM, Rich Bowen  wrote:
> 
> This week, I’ve been approached by someone concerned about one of our 
> projects, and looking for a “how to get back on track” document, with 
> concrete, actionable steps that a project can take when it is struggling to 
> find contributors. This seems like a great doc that we should write. What 
> comes to mind is:
> 
> * Clearly tell the dev@ and user@ list that the project is at risk if they 
> don’t step up
> * Publish a list of open issues to the Dev list
> * Contact companies that you know rely on your outputs, and tell them that 
> the project is at risk
> * Clearly document the path/requirements for getting committer. Consider 
> lowering your wall a little
> * What else?
> 
> Another question that I have is where to put this doc. I’m thinking it goes 
> in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but 
> I’m not sure that to name it.
> 
> 
> 
> — 
> Rich Bowen
> rbo...@rcbowen.com
> 
> 
> 
> 

Re: [WG] Workgroups update

[Rich Bowen]

> On Mar 29, 2024, at 10:21 AM, Gary Gregory  wrote:
> 
> Thank you for following up.
> 
> How would I signal my interest in or join a working group? Maybe I missed
> that part.

I have several answers to this, but the main one is that we’re not sure yet, 
and would love your help in defining that. The “workgroup workgroup” was, 
conceptually, a place where we’d discuss how to manage/govern the workgroups, 
but that hasn’t gotten any love yet.

I think other answers would be 1) Add yourself to the Readme, 2) start 
discussing, here, on this list, what you’d like to accomplish and 3) starting 
to do those things, while keeping up a running commentary of what you’re doing, 
and how other folks can get involved.

The main thing that I want to emphasize is that I’m not the leader here. What I 
want more than anything is for folks to step up and take some of these things 
and run with them. I think they all desperately need to be done, but I only 
have time for one or two of them, myself.

—Rich



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


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

Re: Getting a project back on track

[Rich Bowen]

On Mar 29, 2024, at 10:20 AM, Michael Sokolov  wrote:
> 
> I guess it depends on what the problem with the project is. It seems
> implicit in your ideas that the project has lost momentum; nobody is
> contributing to it or maintaining it actively? But I just want to
> point out there can be other problems that might need correction with
> different solutions (too much chaos, fighting, legal issues, poor
> quality releases, etc)
> 


Yes, those things seem useful to address also.

The most common problem we see in ASF projects is that they just wind down and 
lose steam, and end up being one or two people trying to keep the lights on, 
with no time to go out and find helpers.



> On Fri, Mar 29, 2024 at 9:36 AM Rich Bowen  wrote:
>> 
>> This week, I’ve been approached by someone concerned about one of our 
>> projects, and looking for a “how to get back on track” document, with 
>> concrete, actionable steps that a project can take when it is struggling to 
>> find contributors. This seems like a great doc that we should write. What 
>> comes to mind is:
>> 
>> * Clearly tell the dev@ and user@ list that the project is at risk if they 
>> don’t step up
>> * Publish a list of open issues to the Dev list
>> * Contact companies that you know rely on your outputs, and tell them that 
>> the project is at risk
>> * Clearly document the path/requirements for getting committer. Consider 
>> lowering your wall a little
>> * What else?
>> 
>> Another question that I have is where to put this doc. I’m thinking it goes 
>> in https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but 
>> I’m not sure that to name it.
>> 
>> 
>> 
>> —
>> Rich Bowen
>> rbo...@rcbowen.com
>> 
>> 
>> 
>> 
> 
> -
> 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

[WG] Workgroups update

[Rich Bowen]

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

Getting a project back on track

[Rich Bowen]

This week, I’ve been approached by someone concerned about one of our projects, 
and looking for a “how to get back on track” document, with concrete, 
actionable steps that a project can take when it is struggling to find 
contributors. This seems like a great doc that we should write. What comes to 
mind is:

* Clearly tell the dev@ and user@ list that the project is at risk if they 
don’t step up
* Publish a list of open issues to the Dev list
* Contact companies that you know rely on your outputs, and tell them that the 
project is at risk
* Clearly document the path/requirements for getting committer. Consider 
lowering your wall a little
* What else?

Another question that I have is where to put this doc. I’m thinking it goes in 
https://github.com/apache/comdev-site/tree/main/source/pmc somewhere, but I’m 
not sure that to name it.



— 
Rich Bowen
rbo...@rcbowen.com

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

[Rich Bowen]

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: [WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

> On Mar 20, 2024, at 11:59 AM, Paulo Motta  wrote:
> 
> Rich:
> 
> I need some time to better elaborate this. I will prepare sometime in the
> next week or so a short doc explaining what am I proposing, what problem it
> solves and how it intersects with the badging tool object of this working
> group.
> 
> I suspect we might be thinking about similar things but in different terms,
> right now I’m just doing unstructured brainstorming.
> 
> On the meantime, can you briefly describe what problem are you trying to
> solve with this badging system, and what do you expect from it to ensure
> we’re talking about the same things? If this is already described somewhere
> please let me know and I will use it to check if this intersects with the
> proposal I have in mind.

The purpose of badging is discussed here: 
https://github.com/apache/comdev-working-groups/tree/main/wg-badging

In brief, it’s to celebrate and gamify moments in individuals’ community 
journey. It’s a way for people to brag/celebrate/display their accomplishments, 
since this is something that has been shown to motivate not only participation, 
but for people to expand outside of their usual habitual sphere of 
participation and try other things.

Tying it to Apache IDs is reasonable because this is for us. It’s for our 
community. It’s to make others want to be part of our community, sure, but 
primarily it’s for our community. Having a (very very small, I might note) 
barrier to entry is totally reasonable. And creating a new, separate ID system 
actively defeats the link with the community, not to mention introducing new 
complications.

Celebrating achievements in community is a building block for tighter community 
relationships. I encourage everyone on the ComDev project to read The Art of 
Community by Charles Vogl, because there’s a TON of science around how to build 
community that we, in open source, tend to be largely unaware of, going back 
decades, and we miss out on a LOT of simple low-hanging opportunities to draw 
people in, and strengthen what we have. This is one of them.

Re: [WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

On Tue, Mar 19, 2024, 16:55 Paulo Motta  wrote:

> > it looks like there’s no way to run this on the hosted service and have
> it integrated with ASF LDAP, as each individual badge recipient would have
> to create an account through their tooling.
>
> Backing off a bit, do we really need logins for a badging page? In my view
> this would add unnecessary friction/overhead for contributors without ASF
> IDs, which to me would be the initial beneficiaries of this system.
>

This is a community building tool. Encouraging people to join the community
to use the tool seems entirely reasonable to me.

I must admit that I didn't understand your proposed solution at all and
don't really understand what problem it solves.

Re: Community Over Code NA community track, CFP closing soon

[Rich Bowen]

> On Mar 19, 2024, at 10:43 AM, Rich Bowen  wrote:
> 
> Hey, folks,
> The CFP - Call for Presentations - for Community Over Code North America is 
> closing very soon - at 23:59 UTC on April 1, 2024
> 
> https://communityovercode.org/call-for-presentations/
> 
> As usual, we will have a community track, covering all manner of community 
> content, such as governance, onboarding, community growth, and so on. We 
> almost always have twice as many submissions as we can reasonably run, so 
> please do write your abstracts carefully with that in mind, and wow us with 
> your presentation ideas.
> 
> We hope to see many of you in Denver!

Amusingly, the deadline changed literally as I was writing this email. It’s the 
15th now, rather than the 1st, but please don’t take that as a reason to delay 
further.

—Rich

Community Over Code NA community track, CFP closing soon

[Rich Bowen]

Hey, folks,
The CFP - Call for Presentations - for Community Over Code North America is 
closing very soon - at 23:59 UTC on April 1, 2024

https://communityovercode.org/call-for-presentations/

As usual, we will have a community track, covering all manner of community 
content, such as governance, onboarding, community growth, and so on. We almost 
always have twice as many submissions as we can reasonably run, so please do 
write your abstracts carefully with that in mind, and wow us with your 
presentation ideas.

We hope to see many of you in Denver!

— 
Rich Bowen
rbo...@rcbowen.com

Re: Reporter tool for board reports needs some love

[Rich Bowen]

> On Mar 18, 2024, at 5:18 PM, Craig Russell  wrote:
> 
> Hi,
> 
> Is there anyone who can take a look at the Reporter tool that many projects 
> rely on to help create board reports?
> 
> A number of projects have commented that the statistics seem to be in 
> conflict with reality.

Every month several projects make this complaint. I almost always encourage 
them to bring their complaint here. They almost never do, leaving us with only 
the vaguest idea of what they think is broken. Do you feel you understand what 
they think is being reported inaccurately? I think some folks have complained 
about Github stats being off, but that’s pretty easy to go retrieve on their 
own.

[WG-website] Front page is a mess

[Rich Bowen]

Hi, folks,

I would very much like to tackle the front page of the community.a.o website. 
It’s a massive wall of text, none of which any human is ever going to read. 
Unfortunately, I lack web design skills, but I feel like if I don’t dive in and 
start to make something happen, we’ll just be stuck with this forever.

So … if you would like to be involved with that, please do let me know, either 
here or on Slack. Otherwise I’m going to just dive in and start breaking things.

Thanks.

— 
Rich Bowen
rbo...@rcbowen.com

[WG: Badging] Tooling, reclaiming thread

[Rich Bowen]

Ok, since the existing “Tooling” thread has been hopelessly derailed into … 
whatever that is, I’m going to try to reboot this thread.

So far, we have a proposed solution from Paulo:


> I've played around with badgr.com <http://badgr.com/> a bit and was able to 
> create the
> following organization and badge very quickly (the site usability is pretty
> good):
> - ORG: https://badgr.com/public/issuers/bumbzeisQSuoN3Q_G4753Q/badges
> - BADGE:
> https://badgr.com/public/assertions/ROzmBXUXQ9Cs86uMYdrGvA?identity__email=pauloricardomg%40gmail.com

After poking through this a bit, it looks like there’s no way to run this on 
the hosted service and have it integrated with ASF LDAP, as each individual 
badge recipient would have to create an account through their tooling. This 
rather violates the “easy” requirement.

Anyone have any insight into if, or how, we might do that, or another badging 
tool that may make this easier?

— 
Rich Bowen
rbo...@rcbowen.com

Re: [WG: Badging] Tooling

[Rich Bowen]

> 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: Badging] Tooling

[Rich Bowen]

On Mar 8, 2024, at 9:19 AM, Rich Bowen  wrote:
> 
> I attended a talk last week at FOSS Backstage by Spot Callaway, who started 
> the Fedora badges program. He said that the guiding principles are:
> 
> * It should be fun, not legalistic. 
> * It should celebrate non-code accomplishments at least as much as code ones
> * It should be easy - it should celebrate people automatically for stuff 
> they’re already doing, rather than requiring them to go out of their way to 
> request something, or jump through hoops somehow.
> * We should be able to give badges manually, so that we can celebrate 
> spontaneous things. The example given here is that at every conference where 
> Fedora has a presence, there’s a QR code that, if you scan it, you get a 
> badge. This allows people to get badges for everything from attending an 
> event to landing a patch to sending email to a list to whatever we can think 
> of.

FYI, Spot sent me the full notes from that slide:

1. It needed to be fun. The artwork should reflect that, it doesn’t need to be 
boring and corporate.
2. It needed to be easy. You should just start getting badges for the things 
you’re doing.
3. It needed to be collaborative. Beyond the badge code being open source (it 
was & is), people should be able to suggest new badges
4. It must go beyond code. Code is easy, other contribution types are harder, 
but we should do everything we can.
5. We should have a way to award badges manually, aka, not from the message 
bus. This allowed us to do badges for “visiting Fedora at an open source 
event”, which turned out to be one of our most popular badge types.

Re: [WG: Badging] Tooling

[Rich Bowen]

Let me state this more clearly:

> 
> If someone never logged in, they would never see their badges. That is common 
> to all of the badge platforms that I have looked at.

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.

I have yet to meet people who hate being acknowledged for their work, but in 
the event that they exist, they should not be troubled by this system.

It’s important to remember that “I don’t get value from this” is seldom the 
same thing as “nobody will get value from this.”

—Rich

Re: [WG: Badging] Tooling

[Rich Bowen]

> On Mar 8, 2024, at 10:24 AM, sebb  wrote:
> 
> Some people may not want badges; they should not be forced to have
> them if they happen to meet the criteria.
> I agree that opt-in is necessary.
> 

If someone never logged in, they would never see their badges. That is common 
to all of the badge platforms that I have looked at.

The notion that someone would be *forced* to receive congratulations is 
confusing to me. No, nobody is ever *forced* to accept congratulations. But the 
notion that we should refrain from congratulating people until they ask us to 
is rather contrary to how normal social interactions happen.

> Personally, I do not see the point of them.

That’s merely an indication that you’re not the target audience.

Meanwhile, the Fedora Badges system is hugely popular, and makes people feel 
appreciated, which seems like a laudable goal.

Re: [WG: Badging] Tooling

[Rich Bowen]

> On Mar 3, 2024, at 11:47 AM, Paulo Motta  wrote:
> 
> I've thought a bit more and rather than starting with multiple badges, it
> probably makes more sense to start with a single badge to validate the
> idea. More can be proposed later if the first one is shown to be effective.
> 
> I'd propose a pilot badge called 'My First Open Source Contribution'
> awarded to anyone first's contribution to an Apache project that opts-in to
> this badge. This recognition is straightforward to compute and would allow
> testing the program.

I do not think that we need projects to opt in to this. Badges are not aimed at 
projects. They are aimed at *people*.

I attended a talk last week at FOSS Backstage by Spot Callaway, who started the 
Fedora badges program. He said that the guiding principles are:

* It should be fun, not legalistic. 
* It should celebrate non-code accomplishments at least as much as code ones
* It should be easy - it should celebrate people automatically for stuff 
they’re already doing, rather than requiring them to go out of their way to 
request something, or jump through hoops somehow.
* We should be able to give badges manually, so that we can celebrate 
spontaneous things. The example given here is that at every conference where 
Fedora has a presence, there’s a QR code that, if you scan it, you get a badge. 
This allows people to get badges for everything from attending an event to 
landing a patch to sending email to a list to whatever we can think of.

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.

If you have an apache ID, you should be able to start earning badges. The first 
time you sign into the badge system, you should already have a badge, because 
you’ve signed the ICLA and have an apache ID, which is, itself, an 
accomplishment. The bar should be *SUPER* low on this.

Re: Query about the GitHub statistics for Lucene

[Rich Bowen]

Looks like the .invalid in your email address caused my response to go
astray.

The second half of your question: https://reporter.apache.org/about.html

Unfortunately the tool is not actively maintained at the moment. We could
certainly use some more eyes and fingers on it.


Rich

On Tue, Mar 5, 2024, 09:20 Chris Hegarty
 wrote:

> Hi,
>
> Resending, as I have not seen a reply and the anomaly is still not
> resolved.
>
> -Chris.
>
> > On 23 Feb 2024, at 09:19, Chris Hegarty 
> wrote:
> >
> > Hi,
> >
> > I have a query about the GitHub statistics that are being generated the
> Lucene project [1]. They appear to be not accurate, or at least something
> is not quite right with them.
> >
> > For example, I (as well as many other project members) opened several
> issues and PRs in Jan and Feb of 2024, but the graphs show no activity [2].
> >
> > Can someone please take a look at why this might be the case, or
> redirect me to the right place where I can further understand how to
> resolve this.
> >
> > Thanks,
> > -Chris. (Lucene PMC Chair)
> >
> > [1] https://reporter.apache.org/wizard/statistics?lucene#commitactivity
> > [2]
> https://reporter.apache.org/wizard/statistics?lucene#githubpractivity
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [WG: Badging] Tooling

[Rich Bowen]

> On Feb 29, 2024, at 9:44 AM, Paulo Motta  wrote:
> 
>> The most promising of these was Badgr (https://badgr.com/) which seems to
> have become a paid service, and not open any more.
> 
> An active fork of badgr is available on
> https://github.com/edubadges/edubadges-server.

I note that it’s AGPL. Does that cause anyone concern?

> 
>> can someone step up to do the research to find one?
> 
> I've played around with badgr.com a bit and was able to create the
> following organization and badge very quickly (the site usability is pretty
> good):
> - ORG: https://badgr.com/public/issuers/bumbzeisQSuoN3Q_G4753Q/badges
> - BADGE:
> https://badgr.com/public/assertions/ROzmBXUXQ9Cs86uMYdrGvA?identity__email=pauloricardomg%40gmail.com

Cool. Thanks for digging deeper than I did. :) 

Are you suggesting that we use this service? I’m a little concerned about a 
free-to-use service, because there’s no protection against them suddenly 
changing that model when they realize we have *thousands* of users. Would 
probably be worth having a conversation with them about their available plans.

> 
> I've added more details about the fields required to create badges on this
> comment:
> -
> https://github.com/apache/comdev-working-groups/pull/26#issuecomment-1970310015
> 
> If moving forward with badgr make sense I can create a spreadsheet for
> folks to suggest badge types so we can get them set up. Then we can
> advertise to projects who can opt-in to the badging system.

I think that work can happen in parallel to choosing a tool, so, sure, go ahead!


> 
> We could initially emit badges manually and later work on automating the
> process with stats from contribution feeds.



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

[WG: Badging] Tooling

[Rich Bowen]

So … a few years ago, I looked for badging software, and there were several 
options. It appears that all of them have been acquired and made non-open. The 
most promising of these was Badgr (https://badgr.com/) which seems to have 
become a paid service, and not open any more.

Another one - https://openbadges.org/ - appears to have become a group 
promoting a standard for badges, but not actually providing a reference 
implementation. There are several “certified” implementations 
(https://site.imsglobal.org/certifications?refinementList%5Bstandards_lvlx%5D%5B0%5D=Open%20Badges
 ) but I don’t know if any of those are open source.

My canonical version of badging done well, as I mentioned in the README, is 
Fedora Badges - https://badges.fedoraproject.org/ - but while it is, 
technically, open source (https://github.com/fedora-infra/tahrir), it’s also 
very Fedora specific, and past attempts to get it to be more generic were not 
welcome. (Mostly because, at the time, they, too, were planning to move to a 
more general purpose solution, which, since that time, has gone non-open.)

I am *very* reluctant to write something (and, no, I don’t mean me personally, 
but *us*) because that will be a forever project that will likely end up 
unmaintained, like several endeavors in the past. But I suppose that’s an 
option. I just feel like it should be a last resort.

Are any of you aware of a badging solution that we can use? Or, can someone 
step up to do the research to find one?

— 
Rich Bowen
rbo...@rcbowen.com

[WG: Badging] Proposed working group

[Rich Bowen]

TL;DR: https://github.com/apache/comdev-working-groups/pull/26

Over the years, we’ve discussed a badging/achievement system, but have never 
actually figured out the details around doing it. This is a proposal for a 
working group to figure out what’s necessary, and determine whether we want to 
set up such a system.

I’m interested in being part of the discussion, but don’t want to be the only 
one driving it, since I’m already taking on too much. But I didn’t want to drop 
a conversation that comes up several times a year, as far back as I can 
remember.

— 
Rich Bowen
rbo...@rcbowen.com

Re: Web site checker needs help

[Rich Bowen]

> On Feb 28, 2024, at 3:01 AM, Bertrand Delacretaz  
> wrote:
> 
> On Wed, Feb 28, 2024 at 1:28 AM Craig Russell  wrote:
>> ...Is it worth creating a new community-working-group-site-check to document
>> the issues with the tool?...
> 
> Whimsy is created and managed by the https://whimsical.apache.org/
> PMC, why not make that happen there?


It’s tricksy, too, because ComDev is an advisory, peer, project, NOT a policy 
enforcement agent. That tool is 100% about policy enforcement, and so I’m very 
leery of ComDev getting involved in that work. This feels like a blurring of 
the separation of hats that we want to steer away from.

Re: [WG: Welcome] Proposal, a Welcome Working Group - onboarding too?

[Rich Bowen]

> On Feb 25, 2024, at 5:10 PM, Shane Curcuru  wrote:
> 
> Rich Bowen wrote on 2/7/24 11:53 AM:
>> Proposed: A formal working group around how we welcome new folks in a 
>> consistent and helpful manner.
>> We get people on this list (and on every dev@ and user@ list at the 
>> foundation) asking how to get engaged. We almost always give them unhelpful 
>> answers, and send them off to go figure it out on their own.
>> The Welcome WG would write documentation, and process, around welcoming 
>> these new folks, and shepherding them towards engagement. This would 
>> include, but not be limited to:
> ...snip...
> Question: should the wg-welcome group include reviewing all onboarding 
> materials too, or does that deserve it's own group at some point?  They are 
> closely related, but onboarding is a larger topic.
> 


I could definitely see it as a separate WG. I don’t want to spend a lot of time 
creating a huge pile of WGs before anybody is actually committed to working on 
any of them, but if we have people show up to do this work, then splitting 
would make a lot of sense. They are, indeed, closely related but not the same 
thing.


> "Welcoming" is about creating easy to re-use content to help answer simple 
> questions all around, and guiding newcomers - or existing contributors who 
> answer questions! - to the right kind of path, and in a friendly and 
> consistent way.
> 
> "Onboarding" I see as reviewing and updating the actual emails, boilerplate, 
> and links that we send to anyone who is being welcomed to a new role at the 
> ASF - committer (on any project, or on an additional project), PMC member, 
> officer, Member, etc.
> 
> I've already listed the majority of actual sources our tooling actually mails 
> or includes links to people in various places:
> 
> https://cwiki.apache.org/confluence/display/COMDEV/Proposal%3A+Improving+Onboarding+Experiences
> 

Yeah, that’s definitely a lot of work that we need to do, and looks like very 
actionable “where can I jump in” projects. Still struggling with the part of 
the process where we actually find people to *do* the work.


> We need a focused group to start reviewing these, and updating them to be 
> consistent, friendly, and useful for newcomers.
> 
> -- 
> - Shane
>  Member
>  The Apache Software Foundation
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 


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

Re: Query about the GitHub statistics for Lucene

[Rich Bowen]

The second half of your question: https://reporter.apache.org/about.html

Unfortunately the tool is not actively maintained at the moment. We could
certainly use some more eyes and fingers on it.

Rich

On Fri, Feb 23, 2024, 03:20 Chris Hegarty
 wrote:

> Hi,
>
> I have a query about the GitHub statistics that are being generated the
> Lucene project [1]. They appear to be not accurate, or at least something
> is not quite right with them.
>
> For example, I (as well as many other project members) opened several
> issues and PRs in Jan and Feb of 2024, but the graphs show no activity [2].
>
> Can someone please take a look at why this might be the case, or redirect
> me to the right place where I can further understand how to resolve this.
>
> Thanks,
> -Chris. (Lucene PMC Chair)
>
> [1] https://reporter.apache.org/wizard/statistics?lucene#commitactivity
> [2] https://reporter.apache.org/wizard/statistics?lucene#githubpractivity
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [PR] Prototype "volunteers" page (comdev-site)

[Rich Bowen]

I've not had a chance to review carefully because I'm traveling but I love
the idea and am +1 to the patch in concept. Since it is replacing something
that doesn't work, I see no risk in moving forward with this. Thanks!

Rich

On Fri, Feb 23, 2024, 03:44 bdelacretaz (via GitHub)  wrote:

>
> bdelacretaz commented on PR #146:
> URL:
> https://github.com/apache/comdev-site/pull/146#issuecomment-1961010970
>
>I'm planning to merge this early next week unless someone objects.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

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

[Rich Bowen]

On Wed, Feb 21, 2024, 12:40 Christian Grobmeier 
wrote:

>
> On Wed, Feb 21, 2024, at 10:43, tison wrote:
> > Hi Chris,
> >
> > Thanks you. Now we found a volunteer to improve the jekyll template and
> > it's good :D
>
> Haha ok great, I will send a patch as suggested. I can also commit
> directly if this repo is using CTR
>

Yep. Comdev in general is CTR.

Re: [PR] Change Sharpeners to Advisors advisors [comdev-working-groups]

[Rich Bowen]

Thanks. Merged.

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 19, 2024, at 2:26 PM, dave2wave (via GitHub)  wrote:
> 
> 
> dave2wave opened a new pull request, #10:
> URL: https://github.com/apache/comdev-working-groups/pull/10
> 
>   (no comment)
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
> 

Re: [WG: Sharpeners] Propose: milder name

[Rich Bowen]

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
> 

Re: [WG: Sharpeners] Propose: milder name

[Rich Bowen]

> 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

Re: [WG: Sharpeners] Propose: milder name

[Rich Bowen]

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

Re: [WG: Sharpeners] Proposed: Escalation advice

[Rich Bowen]

Sorry, I managed to miss the second half of your email.

> On Feb 16, 2024, at 1:12 PM, Dave Fisher  wrote:
> 
>> https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md
> 
> It’s spelled “escalation”. In addition you use the term mentors here where 
> there are already two other roles in the foundation that use this term.
> 

Spelling fixed. Adjust URL accordingly.

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

Is that a problem? Surely mentoring is the *primary* thing that ComDev does.


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

Everyone needs mentors at different points in their lives. Incubation is a 
process, with an end point. Projects do not cease needing mentoring once they 
have graduated from the Incubator.

As to who decides,  well, this is a volunteer-driven process in a 
volunteer-driven org, so I’d say it’s entirely voluntary. As discussed in the 
conversation with Jarek earlier today, I think there are two possible entry 
points. Either a PMC comes to ask for help, or an individual is interested in a 
particular project community and shows up to learn about it, and sees places 
where they could be strengthened. In this latter case, a very useful data point 
would be reading board reports, and noticing the frequent times that projects 
indicate that they need a little nudge on some issue or other.

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

I thought I had. Please do feel free to improve my phrasing.

> 
>> I’m sincerely hoping that this kind of explicit process/advice will help to 
>> avoid the perception which I’m seeing from more than one place that this is 
>> just a way for people to be policemen in our projects.
> 
> It does help.
> 
> I think that there should be a section that the sharpener’s advice and/or 
> questions of the PMC should be consolidated into singular well thought out 
> messages and not several disjoint emails where the threads lose context.

PRs welcome, although I’m not entirely sure what you mean here.

> 
>> 
>> Let me know what y’all think.
> 
> I may provide a PR over the weekend ….

Awesome. Thanks.

Re: [WG: Sharpeners] Proposed: Escalation advice

[Rich Bowen]

> On Feb 16, 2024, at 1:12 PM, Dave Fisher  wrote:
> 
> I have a couple of overarching comments.
> 
> A. Why “Sharpener”? I don’t really want to bike shed the name, but here are 
> definitions:
> 
> 1. a device or tool for making something sharper, esp. pencils or knives:
> 2. (Slang)  An alcoholic drink taken at the start of the day, or just before 
> a meal.


I’ve never heard #2, but, ok.

This question is directly addressed in the README:

-

### Why "Sharpener"

Because I wanted an "sh" word, to go along with Shepherds and Shadows,
which I'll be writing about elsewhere.

"As iron sharpens iron, so one person sharpens another.”

——

We already have Shepherds. I will be proposing a Shadow concept soon - still 
writing that up. Alliteration is cool.


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

Well, ok, but, no, I hadn’t thought of that.


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

The board explicitly asked us to develop this concept, back in June:

https://lists.apache.org/thread/4fswg0t0q5vthztc7gpfj4snc1ol2jxn

Granted, I was the one that wrote that proposal, but it was at the direction of 
the whole board, and was approved by the whole board.

So, yes.

[WG: Sharpeners] Proposed: Escalation advice

[Rich Bowen]

I wrote a (proposed) thing:

https://github.com/rbowen/comdev-working-groups/blob/main/wg-sharpeners/escallation.md

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

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

Let me know what y’all think.

— 
Rich Bowen
rbo...@rcbowen.com

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

[Rich Bowen]

Bit of a long message here, but that’s because I’m trying to address your many 
disparate points.

Jarek,

I am sensing TWO things in your message.

1) You are concerned that we are instituting a police state

2) You have a subtly different understanding of what it is that I’m trying to 
do here than I do.

I’d like you to notice, explicitly, that every single one of the working groups 
I have proposed has this in common: It is not creating a new activity. It is, 
rather, putting structure around something that we are already doing, 
specifically so that it will encourage more people to do it. Structure helps 
some people have the courage to get involved.

Sharpening, for example - you are already doing it. I am already doing it, very 
intentionally, in several different projects, although we don’t call it that.

This working group intends to create consistency and best practice, so that 
more people will do it. That’s all.

> On Feb 15, 2024, at 6:39 PM, Jarek Potiuk  wrote:
> 
> 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.

People who are interested in a project, and helping it out, can go become part 
of that project. That’s how it’s always been. Nobody is *ever* assigned a 
project to go get involved in, and this program would not create any such 
assignments. That would be contrary to how we do things at Apache. The Board is 
not involved in this at all, and would never be.

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

Today, individuals choose project to go get involved in. That’s how you got 
involved in the projects that you work on. The Board has no say in what 
projects you or I are involved in. Nothing in this working group proposal 
changes that. It merely creates tools and structure around what we’re already 
doing. Again so that more people will feel empowered/permitted to do it.


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

I am completely unclear what you’re proposing here. Accidental? People get 
involved in projects because they’re interested in the project. Nobody is 
assigned a project to work on. We are a volunteer organization. Maybe you can 
explain what risk you’re trying to avoid here?

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

Well, ok, sure, I could see a PMC approaching ComDev and saying “can someone 
help us?” That already happens. But, also, I can see an individual getting on a 
PMC mailing list because they see something that they think needs help. That’s 
how we do things today. It’s the nature of my involvement in every Apache 
project I’m currently involved in. Again, I’m unclear what risk you’re trying 
to avoid.

Please remember that this working group is NOT a board project. It’s a working 
group of peers.

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

Sure, ideally, we aim for that kind of diversity in everything we do.


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

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

[Rich Bowen]

>  I just have strong feelings about
> community self-governance and understanding and I will be honest about the
> fact that I am worried about creeping legalism at the ASF.  Instead of
> looking for symptoms, I think Sharpeners should be looking for, and aiming
> to help with, basic challenges.   In the use cases, I dumped vague
> descriptions of some challenges.  They may be wrong and it might be better
> to just provide some kind of engagement path for Sharpeners and let them
> dig in.  What I don't want to see is "red flags" leading to Sharpeners
> showing up and distracting communities from solving real problems or making
> them think they have problems when they don't.


Sure, that’s a fair criticism. And I think the way forward is to consider these 
items and think about what the underlying problem is - or, more helpfully, what 
*recommendation* we would want to make to such a project, and transform this 
list into, instead, a list of solutions (or additional entries in the use cases 
file) rather than problems?

> 
> I will provide a concrete example here that I hope won't offend anyone


It’s a good example, for sure, of someone well-meaning trying to fix a problem. 
It feels useful to consider how we would have wanted this handled instead, with 
that insight and insider knowledge. Just leave well enough alone? Find a way to 
better communicate what’s happening? Encourage other projects to similar 
patterns? (I honestly don’t know, because I wasn’t involved in that situation.)

> 
> The point of the example is that the real problems (and others that I may
> be personally blind to) can only be seen by observing and engaging with the
> community.  When I was a new board member, I used to try to do this for the
> projects that I was shepherding.  It soon became more work than I had time
> to do consistently, but I always tried.  I see the Sharpeners as a
> potential source of people to do this.  It might actually be best not to
> have "triggers" for engagement at all other than requests from the
> communities themselves.  Maybe just assign people on some kind of rotation
> like the Board shepherds.  That would have the positive side effect of
> Sharpeners getting to learn from healthy communities too.

I guess I was thinking (but hadn’t written anywhere yet) that the trigger would 
be reading board reports, and thinking, hmm, that project looks like it might 
need some help. I would *love* to see requests from the communities. And, 
indeed, we have gotten those, over the years, here on the dev@community list, 
and didn’t have any process for saying yes. So perhaps the mechanism is to 
advertise this service to projects, and wait for takers. Then advertise 
successes. Repeat.

What I’ve found as board shepherd is that you never get a deep enough knowledge 
of any given project to really be particularly helpful. Each month when I’m 
shepherding, I’m spending 20 minutes, maybe, on each shepherd project. That’s 
*definitely* not enough time for the kind of deep dive I think we’re both 
talking about. My hope is that a sharpener, unlike a shepherd, would spend 
enough time listening that they would actually start to understand what they’re 
hearing, and become a legitimate member of the project community.

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

[Rich Bowen]

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

After a night’s sleep and pondering on what we’re doing here, I want to really 
encourage all of us to view this, in perpetuity, as a work in progress. If you 
see problems with the approach, please suggest solutions, rather than raging at 
the darkness.

It’s ironic that the response to a list of things that a project can do wrong 
is to say that we’re doing it wrong, n’est pas?

Having a list of “bad smells” is part of the process of getting to what work we 
want to do. It’s not the end product.

What I’m really hoping for, out of this working group, is a unified approach 
that we can use to improve the Foundation as a whole, and sharpen one another, 
collectively, to make the ASF live up to its promise. That is always going to 
be aspirational. We’re not going to get there. Not for not trying, but because 
we are several thousand humans with egos and motivations. But we can work 
together to hone the edge a little.

The work, for the moment, is achieving some rough consensus, and that involves 
respectful conversation. If we cannot sharpen ourselves, in this tiny group of 
folks who have known one another for a decade or more, we have very little 
chance of approaching a project full of strangers and trying to guide them.

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

[Rich Bowen]

On Feb 14, 2024, at 2:46 PM, Phil Steitz  wrote:
> 
> I guess I am too late here, but fwiw, I agree strongly with Rich's
> comment.  I would much rather see the checklisty stuff incorporated into
> either the use cases or the main doc somewhere and not presented as "things
> 'we' are looking for".  I do not like at all the statement in the intro to
> the new doc,
> "However, having an idea of what red flags we're looking for
> in a project can be a helpful way to start looking for places to mentor,
> and sharpen, our projects."


You are definitely not too late here, and I would certainly hope that nobody 
feels that I have any more say than anybody else in what we do here. I 
instigated. I am not the leader. Please own the document, and edit it in 
whatever way you see fit.

> 
> That is absolutely the wrong message to give.  Who is "we"?   This kind of
> thing sets the tone of the working group as some kind of external policing
> / inspecting function.  That will not help.
> 

Yes, that is indeed my concern.

> What *will help* is people showing up, listening and coming up with useful
> suggestions for how to solve problems that communities are facing.  In some
> cases, that may actually mean helping them explain why their way of doing
> things is perfectly fine.  I was shocked, for example, by "too many release
> candidates"  on the list of "red flags."   That is ridiculous, IMO, and
> nobody's business but the community.  A sharpener certainly might help
> share experience about how other projects have handled packaging, testing
> and deployment issues, but just jumping in because a few releases have
> burned through a few RC numbers makes zero sense.

Please do take that document as a 0.001 version, and edit/update/delete it as 
you see fit. We are in the “what if” phase here.


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

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

[Rich Bowen (Jira)]

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

Rich Bowen commented on COMDEV-543:
---

Added to doc in https://github.com/apache/comdev-working-groups/pull/2

> Sharpeners use cases
> 
>
> Key: COMDEV-543
> URL: https://issues.apache.org/jira/browse/COMDEV-543
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: use-cases.md
>
>
> Brain dump of ideas for sharpeners use cases



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

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

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

[Rich Bowen (Jira)]

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

Rich Bowen commented on COMDEV-543:
---

These are all good, but I am *very* concerned that we would be, or be perceived 
as, a bunch of heavies showing up to Enforce The Rules. We should endeavor to 
ensure that any list of Red Flags is offset by a list of best practice and good 
advice. Because scolding people for breaking the rules is *much* easier than 
giving good advice, and I am concerned that people wishing to get involved will 
see that as an easy way in, and thus poison the well for the program in general.

> Sharpeners use cases
> 
>
> Key: COMDEV-543
> URL: https://issues.apache.org/jira/browse/COMDEV-543
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: use-cases.md
>
>
> Brain dump of ideas for sharpeners use cases



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

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

[WG] Workgroups repo moved to git

[Rich Bowen]

The workgroups repo has now moved to 
https://github.com/apache/comdev-working-groups

Please adjust accordingly

Zili, can you close the ticket you opened? I appear to not have permission to 
do so.

— 
Rich Bowen
rbo...@rcbowen.com

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

Thanks, Phil. Patches applied. This is all good stuff.

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 12, 2024, at 5:21 PM, Phil Steitz  wrote:
> 
> Sorry, last message got away from me.  The point of the use cases is to get
> a rough consensus of the kinds of things that a Sharpener will work on.
> Ideally, these get a) fixed / better organized and b) fleshed out with
> useful links, suggestions and scope of engagement statements.
> 
> So for example, if "barriers to contribution" survives, we get into what is
> / is not OK for a sharpener to suggest and when it is actually a problem.
> More concretely, consider the case where "some people" think that project
> Foo has an impossibly high bar for commit.  How do you work out what that
> means?  How is it impacting the community?  Both "not a problem" and "yes,
> this is a problem" examples could be added, as well as some info on what
> the Sharpener is allowed to question / how deeply they should engage in
> tweaking internal PMC processes.
> 
> Phil
> 
> On Mon, Feb 12, 2024 at 3:08 PM Phil Steitz  wrote:
> 
>> OK, I added a brain dump on the use cases.  This is in the spirit of "good
>> ideas, bad code" ;)

[jira] [Closed] (COMDEV-543) Sharpeners use cases

[Rich Bowen (Jira)]

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

Rich Bowen closed COMDEV-543.
-
Resolution: Fixed

Thanks. Added in r1915770.

> Sharpeners use cases
> 
>
> Key: COMDEV-543
> URL: https://issues.apache.org/jira/browse/COMDEV-543
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: use-cases.md
>
>
> Brain dump of ideas for sharpeners use cases



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

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

[jira] [Commented] (COMDEV-542) More public tone for sharpeners

[Rich Bowen (Jira)]

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

Rich Bowen commented on COMDEV-542:
---

Thanks. Applied in r1915769.

> More public tone for sharpeners
> ---
>
> Key: COMDEV-542
> URL: https://issues.apache.org/jira/browse/COMDEV-542
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: sharpeners.patch
>
>
> Some suggested changes to Sharpeners README



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

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

[jira] [Closed] (COMDEV-542) More public tone for sharpeners

[Rich Bowen (Jira)]

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

Rich Bowen closed COMDEV-542.
-

> More public tone for sharpeners
> ---
>
> Key: COMDEV-542
> URL: https://issues.apache.org/jira/browse/COMDEV-542
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: sharpeners.patch
>
>
> Some suggested changes to Sharpeners README



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

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

[jira] [Resolved] (COMDEV-542) More public tone for sharpeners

[Rich Bowen (Jira)]

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

Rich Bowen resolved COMDEV-542.
---
Resolution: Fixed

Patch applied

> More public tone for sharpeners
> ---
>
> Key: COMDEV-542
> URL: https://issues.apache.org/jira/browse/COMDEV-542
> Project: Community Development
>  Issue Type: Improvement
>  Components: Comdev
>Reporter: Phil Steitz
>Priority: Minor
> Attachments: sharpeners.patch
>
>
> Some suggested changes to Sharpeners README



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

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

Re: [WG: Social Media] Proposed - Social Media working group

[Rich Bowen]

> On Feb 11, 2024, at 6:24 AM, Slawomir Jaranowski  
> wrote:
> 
> Hi,
> 
> Thanks for the idea ...
> 
> Some time ago we discuss on Maven slack channel who can publish message
> behalf of ASF like announcements about new releases
> 
> Clear rules for ASF wide and for project accounts will be appreciated.

This is why we’re going to have to work closely with MarkPub, since actually 
setting *policy* around this is firmly out of scope. But bringing these 
concerns to MarkPub may lead to the creation of policy (or at least guidelines) 
that we can then help projects implement.

—Rich

Re: [REQUEST] Create apache/community GitHub Repo (WAS: Working groups working group)

[Rich Bowen]

> On Feb 12, 2024, at 10:24 AM, sebb  wrote:
> 
> Why not migrate the SVN repo to Git?
> Is there any need to keep the info in SVN?

FWIW, I have no opinion on this, beyond my fiery and abiding antipathy for Git. 
If that’s what people want, go ahead, and I’ll adjust. This is a discussion. 
I’m not running the show here.


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

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

> On Feb 12, 2024, at 10:57 AM, tison  wrote:
> 
> Thank you for starting this discussion, Rich.
> 
> I'm trying to get the points of this WG:
> 
> 1. This WG is NOT a new office to "shepherd" TLPs, but to write down
> how any community member can help in sharpening an ASF project.
> 2. For applying any suggestions, the request is delegated to the
> Board, Trademarks, or other offices in the case; a member of this WG
> can be an accountable assistant.
> 


Well … yes and no. Ideally, a Sharpener will work with the PMC, offer them 
advice, and the PMC will act on that advice. One hopes that very little, if 
anything, is ever actually escalated to the Board or other officers.

One of the big complaints about the Board is that it only has a big hammer - 
that is to say, the Board doesn’t do nuance. Once something reaches the Board, 
chances are something big is going to happen. And we want to avoid that. We 
want to discover, and address problems, long before they become problems.

Anything that the Sharpener does, literally any member *could* do, but by 
creating a process/structure around this, I hope to

* Make it more acceptable to projects (ie, it’s not personal, this is here to 
help us improve)
* Make it easier for members to get involved in doing this (ie, give permission)
* Reduce the number of escalations to the Board (ie, solve problems before they 
occur)


> So, the main work items of this WG are shaping how any community
> member can "supervise" an ASF project and how to collaborate with
> offices to get TLPs to work well. Also, "ensure" that such guidances
> are put into work.


I am very intentionally trying to avoid words like “supervise.” We are coming 
alongside, and mentoring. We are not in a position of authority. The very first 
Value I stated was that the project has a right to decline.

> 
> If so, I'd recall my previous comment as an Incubator mentor that:
> 
>>> As a podling mentor, I know that many podlings join the ASF by influences 
>>> from other TLPs. So if the TLP violates our policies, it increases the 
>>> friction when we help the podlings to comply with our policies.
> 
> I already worked with trademarks@ to spot and fix issues on a few
> TLPs' content. I'm glad to join this WG to share my experience
> contributing to well-formed guidance.

Excellent. I look forward to collaborating with you on this.



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

Re: [REQUEST] Create apache/community GitHub Repo (WAS: Working groups working group)

[Rich Bowen]

> On Feb 12, 2024, at 10:46 AM, tison  wrote:
> 
>> Why not migrate the SVN repo to Git?
>> Is there any need to keep the info in SVN?
> 
> I'm +1 in this direction. But it doesn't bother me if we keep a gate
> to allow commiting via SVN and sync to GitHub. If Rich likes this way
> and now he is the most active volunteer on this initiative.

I sincerely hope it doesn’t remain that way.


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

Re: [REQUEST] Create apache/community GitHub Repo (WAS: Working groups working group)

[Rich Bowen]

On Feb 12, 2024, at 10:13 AM, tison  wrote:
> 
> According to the INFRA ticket [1], we'd better create the
> apache/community GitHub repo first.
> 
> I'm glad to execute the self-serve command but I'm yet to be a COMDEV
> PMC member. I remember that in another thread, it's said that an
> Apache Member can self-request to be a PMC member, so:
> 
> * If any COMDEV PMC member can create the GitHub repo on self-serve
> platform [2];
> * If it's possible, I'd like to self-request to be a PMC member and do
> the set up by myself.


Done.

Meanwhile, as per ComDev policy, your request to be a ComDev PMC member is 
approved. Swapnil, can you pull the lever, please.

Thanks.

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 11, 2024, at 6:04 PM, Phil Steitz  wrote:
> 
> I am working on a PR to take a stab at tweaking the wording.  I am also
> playing with some ideas around use cases - kinds of things sharpeners will
> work on.  I think it's really a good idea to get some rough consensus on
> what is in/out of scope before we start this.

Indeed. Both what’s in and out of scope, and specific examples would be really 
helpful. I am sure that I have a lot of preconceived notions of how *I* would 
do this kind of work, but one of the major goals of working groups is to 
document this so that people without those assumptions can get involved without 
too much ramp-up time.

Looking forward to your thoughts on this.

Re: New Project Proposal

[Rich Bowen]

Hi, Ayaan,

Thanks for your interest in the Apache Software Foundation.

New projects enter the ASF through the Incubator, which you can read about at 
https://incubator.apache.org/

In particular, this document - https://incubator.apache.org/cookbook/ - may 
help you decide whether the ASF is a good home for your project. It’s kind of a 
long document, but entering the Incubator is a long-term commitment, so it’s 
worth going in informed.

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 10, 2024, at 6:13 AM, Ayaan Khan  wrote:
> 
> Hi everyone,
> 
> Few months back I started an open source project to develop a high
> performance web framework to program web applications in C++ with ease and
> simplicity. The purpose was to promote C++ in the field of web programming
> by providing a very simple API to develop web applications within very few
> lines of code along with the advantage of its blazing fast speed. This
> would allow people to code complex web APIs that require heavy computation
> in C++ easily, it would be highly scalable and would be able to handle
> enormous amounts of requests simultaneously leveraging the cpu throughput
> at its maximum. Currently, this framework is in its early stages, and I am
> thinking of growing it under the Apache umbrella. I think it would be great
> if we add this project to the apache software foundation. Where a lot of
> people would come and contribute to this project. It would be a great
> learning experience for a lot of people among us.
> 
> Please let me know your thoughts on this proposal.
> 
> Thank you.
> 
> Regards,
> Ayaan Khan

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

Yes that's probably a good improvement. My one concern is that one
shouldn't have to be a technical expert in the project to do this work, so
careful wording is necessary.

Rich

On Fri, Feb 9, 2024, 20:49 Phil Steitz  wrote:

> Thanks, Rich.  I think we have been headed in this direction for some time
> now and something like this is needed.  Many thanks for coming up with a
> concrete proposal.
>
> I have one suggestion for improvement, which is in part a problem
> statement.  Instead of just subscribing to the private@ list, I would
> suggest that Sharpeners also subscribe to and even engage primarily on the
> dev@ list.  The problem statement part of this is that having influence
> "behind the curtain" of privacy runs counter to transparency, especially if
> that influence is on how the project is run.  It's been a while since I
> have been on the board, but I remember often pointing to discussions on
> private lists that should be public. I don't think its a good idea to have
> general discussion about how things are done in a project on private lists
> and having the Sharpeners engage exclusively there might encourage more of
> that.  I think its a best practice to post draft board reports to dev lists
> and relay board feedback there.  I know a lot of projects do that.  That
> way, the community understands the thought process and can lead whatever
> change is needed, rather than being surprised by it.   When I look back on
> successful "sharpenings" in the past, the real work generally happened on
> the project lists, with only very sensitive or individual people-related
> things being worked out on private lists.
>
> It might be a good idea to look at some historical examples and tease out a
> little more what exactly "sharpening" is going to be.  If it is primarily
> (re-)education or community transformation, that really does need to be
> public and community-based.  If its more admin / legal / policy compliance,
> that fits with the private engagement of the PMC model.
>
> Phil
>
>
>
>
>
>
> On Fri, Feb 9, 2024 at 6:55 AM Rich Bowen  wrote:
>
> > Ok, this one probably requires a LOT of discussion, but it’s something
> > I’ve been thinking about for more than a year, so if some of this seems
> > like I’ve already wordsmithed it, that’s why.
> >
> > Projects go through the Incubator, learn how to Apache, and then they
> move
> > on. The membership changes. The mission changes. The world changes around
> > them. And the lessons of the Incubator are often forgotten, or deemed
> > unimportant to the changed circumstances.
> >
> > This Working Group provides a mechanism for ASF Members to assist the
> > board in advising projects. (See the FAQ, “Why a member?” before
> objecting
> > to this. I am very firm on this point, and I believe that the board will
> be
> > too, if asked.
> >
> > I want to STRENUOUSLY encourage you to read the entire proposal before
> > responding, because I have foreseen a number of objections to this, most
> of
> > which go under the heading of “who are YOU to tell US what to do?!” I am
> > very cognizant of this. ComDev is a PEER to other projects, not in a
> > position of authority. That said, every member is responsible, to a
> certain
> > degree, for the direction the entire Foundation takes.
> >
> > I believe that this effort, if successful, could be hugely influential in
> > the trajectory of the ASF in the coming years. I believe that this is, at
> > heart, the primary mission of ComDev. I feel very strongly about the
> > importance of this working group. I will be glad to hold forth at greater
> > length over beer and/or scotch, at the next event facilitated by
> wg-social.
> > ;-)
> >
> > Anyways, please read
> >
> https://svn.apache.org/repos/asf/comdev/community/wg-sharpeners/README.md
> > and then think a little bit and then let me know what you think.
> >
> > Proposal also included below for convenience.
> >
> >
> >
> > # Sharpeners Work Group (Proposed)
> >
> > To provide "Sharpeners" - volunteers who come alongside a PMC to offer
> > an outsider's perspective on the project, and advice to build their
> > community.
> >
> > ## Who
> >
> > A Sharpener must be an ASF member. They are preferably a member who has
> > been around a while, and has some reason to be trusted as a mentor. You
> > must not already be a member of the PMC. You must not have any
> > adversarial reason to take on the role - a bone to pick, a corporate
> > entanglement, or whatever.
> >
> > ## What
> >
>

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

> On Feb 9, 2024, at 11:33 AM, Christofer Dutz  
> wrote:
> 
> Hi Rich,
> 
> I love every line of it … the only thing I would possibly “fine tune” in the 
> text, would be to be a bit more explicit:
> “You must not already be a member of the PMC.” -> “You must not already be a 
> member of the PMC that you wish to join as Sharpener.” Cause I was a bit 
> confused which of the many PMCs involved you were talking about.

Thanks. I’ve updated the doc accordingly.


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

Re: [WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

> On Feb 9, 2024, at 10:18 AM, Daniel Gruno  wrote:
> 
> I like this proposal a lot, and would be happy to sharpen some pencil 
> mahogany cases, if allowed (unless this pun was so bad you have to decline my 
> offer).
> 
> I do have one question, which is where this ... report bit 
> would go, would that be entered into the comdev board report?


I think that’s a detail for the WG to work out, in conjunction with the ComDev 
PMC and Chair, but my vision is that if/when any of these WGs start producing 
actual work, we would add a WG section to the ComDev report, and report on that 
work there. It’s an interesting question, though, because it might imply that 
the WG lead must be a ComDev PMC member, so that they *can* make these 
 comments. Or perhaps they just communicate with the PMC Chair 
directly? I’m not sure. We cannot violate PMC confidentially, whatever we do.

*Ideally*, the comments/advice of an effective sharpener would also influence 
things showing up in the individual PMC’s report, too, but there will be cases 
where the Sharpener’s comments are about red flags in the project, and they 
will be asking the board to look into it, escalate, or whatever, since the 
Sharpener themself has no authority to do anything but advise.

[WG: Sharpeners] Proposed - Sharpeners

[Rich Bowen]

Ok, this one probably requires a LOT of discussion, but it’s something I’ve 
been thinking about for more than a year, so if some of this seems like I’ve 
already wordsmithed it, that’s why.

Projects go through the Incubator, learn how to Apache, and then they move on. 
The membership changes. The mission changes. The world changes around them. And 
the lessons of the Incubator are often forgotten, or deemed unimportant to the 
changed circumstances.

This Working Group provides a mechanism for ASF Members to assist the board in 
advising projects. (See the FAQ, “Why a member?” before objecting to this. I am 
very firm on this point, and I believe that the board will be too, if asked.

I want to STRENUOUSLY encourage you to read the entire proposal before 
responding, because I have foreseen a number of objections to this, most of 
which go under the heading of “who are YOU to tell US what to do?!” I am very 
cognizant of this. ComDev is a PEER to other projects, not in a position of 
authority. That said, every member is responsible, to a certain degree, for the 
direction the entire Foundation takes.

I believe that this effort, if successful, could be hugely influential in the 
trajectory of the ASF in the coming years. I believe that this is, at heart, 
the primary mission of ComDev. I feel very strongly about the importance of 
this working group. I will be glad to hold forth at greater length over beer 
and/or scotch, at the next event facilitated by wg-social. ;-)

Anyways, please read 
https://svn.apache.org/repos/asf/comdev/community/wg-sharpeners/README.md and 
then think a little bit and then let me know what you think.

Proposal also included below for convenience.



# Sharpeners Work Group (Proposed)

To provide "Sharpeners" - volunteers who come alongside a PMC to offer
an outsider's perspective on the project, and advice to build their
community.

## Who

A Sharpener must be an ASF member. They are preferably a member who has
been around a while, and has some reason to be trusted as a mentor. You
must not already be a member of the PMC. You must not have any
adversarial reason to take on the role - a bone to pick, a corporate
entanglement, or whatever.

## What

A Sharpener will subscribe to the project's PMC list
(priv...@project.apache.org) and mostly listen. They will comment
constructively when they see something that may be improved. They will
report concerns back to the board, via  sections in the ComDev
report, under a new "Workgroups" section that will be created for this
purpose.

## Values

Interactions by Sharpeners are at the pleasure of the PMC. You do not
have any authority over the PMC.

### Declinable

The PMC must be allowed to say "no thank you" without providing any
reason, and you must respect that decision, and not offer again unless
invited.

### Transparent

When you subscribe to the private@ list, you MUST introduce yourself and
state your purpose, complete with a link to THIS document. You MUST tell
the PMC when you intend to report something back to either ComDev or the
Board.

We will also track, here, in this repository, which Sharpener is
observing which project.

### Non-adversarial

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 PMC should do, providing links to policy or best practice documents
where applicable. Simply criticising is not welcome.

If you cannot operate in this fashion, then this role isn't for you.

### Confidential

(No, this isn't a contradiction to Transparent. Different audiences.)

All communications on private@ mailing lists are confidential. Sharing
information you learned on those lists to anyone outside of the
membership of the ASF is a severe breach of trust.

Do not ever cross-post between private lists with disjoint audiences. In
general, this means don't forward content from a private list to anyone
who is not an ASF member.

All reports on Sharpener activity must be in  sections, unless
you have coordinated with the PMC to include it in *their* report.

### Collegial

You are a colleague - a peer. You are not in a position of authority.
You cannot tell the PMC what to do. You are only an observer, and, at
the indulgence of the PMC, advisor. Do not abuse this relationship.

## FAQ

### Why "Sharpener"

Because I wanted an "sh" word, to go along with Shepherds and Shadows,
which I'll be writing about elsewhere.

"As iron sharpens iron, so one person sharpens another."

### Why a member?

A Sharpener must be an ASF member. This is because doing this job
requires access to a projects private@ PMC mailing list. All ASF members
already have this access.

Furthermore, an ASF member has already earned trust in the context of
the ASF. Trust is transitive - that is, you may not know all members
personally, but each member was nominated and elected by people that
you, in turn, nominated and elected.





— 
Rich Bowen
rbo...@rcbowen.com

[WG: Social Media] Proposed - Social Media working group

[Rich Bowen]

This one’s pretty simple. We need folks who will figure out how to maintain our 
social media presence, and that of our projects, more effectively. We are 
currently not doing awesome at this - at best, we’re inconsistent. At our 
worst, we are sending out messaging that is not aligned with the Foundation’s 
messaging, and that can be harmful, longer term.

I’ve included the proposed charter below, and at 
https://svn.apache.org/repos/asf/comdev/community/wg-social-media/README.md 
<https://svn.apache.org/repos/asf/comdev/community/wg-social/README.md>

I don’t think this one is controversial, but I think that putting some more 
structure around this, and having a group that sets direction, process, 
membership criteria, and so on, would greatly improve our outreach.

Note that this group MUST defer to MarkPub on all things, so we can’t just 
blaze ahead until they have had their input here.



# Social Media Working Group (Proposed)

Use social media to promote Apache communities

## What

Use the @apachecommunity Twitter account, Facebook, LinkedIn, and other
social media outlets to promote Apache communities.

Work with projects to better facilitate their own social media outlets,
and to share Foundation-wide messaging, where appropriate.

Work with MarkPub to ensure that all of the above is done correctly, and
on-message with the rest of the community.

## Who

The WG shall create membership criteria that ensure that you're enabling
people who can responsibly, consistently, positively and coherently be
spokespeople for the ASF. Possibly work with MarkPub to establish some
kind of guidelines or certification?


— 
Rich Bowen
rbo...@rcbowen.com

[WG: Social] Proposed - Social working group

[Rich Bowen]

I’ve added an initial description here: 
https://svn.apache.org/repos/asf/comdev/community/wg-social/README.md

And copied below for convenience.

Part of building community is facilitating in-person (or maybe virtual?) 
gatherings where contributors can share life as humans. Our communities work a 
lot better when we view one another as humans, and not merely words in email 
messages and pull requests. Over the years, we have become increasingly 
fragmented, for lots of very logical reasons. Let’s see what we can do to chip 
away at that a little bit, and reclaim some of our cross-project bonds.


# Social Workgroup (Proposed)

To facilitate social gatherings wherever Apache contributors may be
present.

## Who

Any Apache contributor may be a wg-social member. It's helpful if you
either travel to in-person events, or live in a place where Apache
contributors may gather, such as a large city, or a popular conference
destination.

## What

Arrange social gathering of Apache contributors. The exact parameters of
this are left up to the members of this WG, but intial suggestions might
be:

* Simply notifying attendees that other Apache contributors might be in
  the same location at the same time.
* Arranging a specific time/place for a gathering, whether for a meal,
  drinks, or informal gathering.
* Working with a sponsor to facilitate an actual sponsored event, and
  inviting Apache contributors to that event.
* Resurrect the pa...@apache.org mailing list to coordinate, and
  promote, these events.

## Why

Building strong communities is easier in person. Facilitating informal
non-technical gatherings of Apache contributors, especially across
projects, builds strong bonds within the Foundation, and contributes to
important conversations that affect all of us.

## Values

* You will never spam the membership, or the projects, with excessive
  communication about gatherings. There's probably a lot of leeway to
  interpret this, but everyone knows spam when they see it.
* This is not a mechanism for companies to circumvent our trademark
  policies. Work with trademarks@ to ensure that you're not stepping on
  toes here.
* This is an unfunded, volunteer effort. You don't have access to ComDev
  budget for this, except with regard to foundation swag (stickers, for
  example) that ComDev chooses to provide.


— 
Rich Bowen
rbo...@rcbowen.com

Re: charges from Apache Maven

[Rich Bowen]

Apache Maven is free software, and, as such, we have no record of who has 
downloaded it, or where they are running it, or for what purpose.

The Apache Software Foundation does not operate an Apache Maven hosted service 
(or any other for-pay hosted services), and these charges could not originate 
either with the Apache Maven project itself, or the Foundation as a whole. 
These transactions are not from us. I’m not personally aware of any org that 
hosts for-pay Maven services, so I’m not sure who to point you to. It’s 
possible that someone on the Maven mailing list 
(https://lists.apache.org/list.html?d...@maven.apache.org I think) might know?

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 8, 2024, at 9:44 AM, Daniela Botterbusch Cole  wrote:
> 
> hi-
> 
> Since mid-2023 I've been receiving monthly charges to my Amex card for $13.
> Those charges are linked to Apache Maven Software and the bill request
> comes from Salford GB.
> 
> I have no records in any of my email (or in any of my subscription
> services) of having downloaded or subscribed to anything from Apache or
> Maven, etc. I've looked everywhere.
> 
> I've placed a merchant block on my CC for all future transactions from your
> side.
> 
> However, I would like to get to the bottom of this and understand where the
> charges are coming from and what they are for. If it's for a
> legitimate service I unknowingly use, then I'd need to remove the merchant
> block, etc.
> 
> The account would be linked to either this email address or to
> das...@ailuminate.ai
> 
> Please let me know if you can assist with this. If not, please point me in
> the right direction.
> 
> Best,
> 
> Daniela
> 
> -- 
> Daniela Botterbusch Cole
> (c) 917.531.6345
> das...@gmail.com

Re: [WG: Website] Proposal - Website working group

[Rich Bowen]

I’ve put a couple of docs in 
https://svn.apache.org/repos/asf/comdev/community/wg-website as a starting 
point. Note that someone has already opened an infra ticket to mirror this on 
Github, so if you hate svn, just wait a day or two.

I will be moving my ToDo list, which currently resides on paper here on my 
desk, to the file wip.md so that 1) folks know what I’m working on and 2) 
hopefully some of y’all can come help. Please also add your items there. Or, 
y’know, once we have a GitHub mirror, we can use tickets there instead? I don’t 
feel strongly about this. Just trying to get stuff done.

— 
Rich Bowen
rbo...@rcbowen.com




> On Feb 7, 2024, at 11:11 AM, Rich Bowen  wrote:
> 
> Proposed: Form a formal Website working group.
> 
> (I am aware that I haven’t defined “working group” yet, and I do, in fact, 
> intend to propose a Working Groups Working Group which could possibly 
> formalize what a working group looks like. I have some ideas, but no desire 
> to go define it on my own.)
> 
> The Website WG would, obviously, be responsible for the maintenance of the 
> website. I am aware that some folks think I’m just off doing that on my own, 
> and that’s part of what I’m trying to avoid (see 
> https://lists.apache.org/thread/nwvr28gq51c8v0wkqjv8xvvc2xqrtf03 for further 
> commentary). I would like to gather a group of people who 1) care about it 
> and 2) are willing to do some of (NOT ALL) the work.
> 
> Specific things that I believe we should tackle include
> 
> * Long-term maintenance of the site. This involves regular audits, 
> implementing metrics, and perhaps other things
> * Reorg - this is a short-term task that I’ve been just doing on my own, 
> which ensures it will never get done, and if it did, there may be some 
> disagreement about how I did it.
> * Deduplication - work closely with MarkPub to figure out the *right* place 
> for certain information; work through the policy/best-practice dichotomy and 
> ensure that we are *not* duplicating policy docs; Work on content on www.a.o 
> <http://www.a.o/> that is closely related to content on community.a.o - which 
> one is authoritative? Ensure that we don’t duplicate, contradict, or confuse.
> 
> There’s probably more.
> 
> I would hope that a WG would have regular checkins (could be email, Slack, 
> Google Meet, I really don’t care, as long as everyone is engaging with the 
> conversation.)
> 
> If you are interested in helping form this group, please speak up in this 
> thread, and help us help one another.
> 
> — 
> Rich Bowen
> rbo...@rcbowen.com
> 
> 
> 
> 

Re: [WG: WG] Proposal: Working groups working group

[Rich Bowen]

> On Feb 7, 2024, at 11:22 AM, Rich Bowen  wrote:
> 
> * Where to we want to track WG status? I would propose that we create 
> GitHub.com/apache/community <http://github.com/apache/community> for stuff 
> like this, to mirror GitHub.com/kubernetes/community 
> <http://github.com/kubernetes/community>, at least in spirit, but would like 
> to discuss this with more people

I’ve started putting stuff in https://svn.apache.org/repos/asf/comdev/community

I like svn. If you don’t, please feel free to jump in and make an infra ticket 
to move/mirror that to GitHub.

—Rich

[WG: Welcome] Proposal, a Welcome Working Group

[Rich Bowen]

Proposed: A formal working group around how we welcome new folks in a 
consistent and helpful manner.

We get people on this list (and on every dev@ and user@ list at the foundation) 
asking how to get engaged. We almost always give them unhelpful answers, and 
send them off to go figure it out on their own.

The Welcome WG would write documentation, and process, around welcoming these 
new folks, and shepherding them towards engagement. This would include, but not 
be limited to:

* Guiding projects towards the incubator. This includes the “why would you want 
to be at Apache? Why would you *NOT* fit at Apache?” documentation that we 
really don’t have yet.
* Guiding brand-new contributors towards how, and where, to contribute. This 
may include working with some of our more welcoming projects to figure out best 
practice, and our less-welcoming projects to figure out why they are and help 
them fix that.
* Working with second-time contributors to encourage best practice. (See 
https://mikemcquaid.com/stop-mentoring-first-time-contributors/ for thoughts on 
first- vs second-time contributors)
* Crafting boilerplate answers to send to folks who show up asking for help 
getting involved, so that we don’t continue this practice of unhelpful “go 
figure it out on your own” responses.
* Maybe work on some kind of a badging program (See 
https://badges.fedoraproject.org/ if you don’t know what I mean by that) to 
incentivize and gamify community engagement, for reasons that I would love to 
talk much more about, but are beyond the scope of this proposal.

What do y’all think?

— 
Rich Bowen
rbo...@rcbowen.com

[WG: WG] Proposal: Working groups working group

[Rich Bowen]

Proposed: A Working Group to help define Working Groups

No, I’m not suggesting a top-down governance of working groups. What I’m 
suggesting is a group to discuss what a working group looks like and what kind 
of tools and processes we want to put in place to make sure that each WG isn’t 
inventing everything from scratch every time. This also makes it easier for 
folks to get involved in WGs, if they all look similar, and you don’t have to 
relearn everything every time.

Topics would include:

* Where to we want to track WG status? I would propose that we create 
GitHub.com/apache/community for stuff like this, to mirror 
GitHub.com/kubernetes/community, at least in spirit, but would like to discuss 
this with more people
* Define an actual data file (See 
https://github.com/kubernetes/community/blob/master/sigs.yaml for a possible 
template) that tracks what WGs exist, who’s involved, what they’re working on. 
Or perhaps this is too heavyweight. Dunno. I just want to make these things 
more discoverable
* Responsibilities. For example, I think a WG should report to the ComDev PMC, 
for visibility, accountability, and to show the board that we’re actually doing 
stuff.
* Membership. Who can be a member of a WG? What’s the connection between WG 
membership and comdev committer status? Do we need a formal WG chair, or is 
that too heavyweight?

I imagine that the WG WG would be short-lived, although anything decided can 
obviously be revisited, and evolve over time.

And nothing here should be construed as “you can only do stuff if you stay 
within these guard rails.” It’s just intended to give more structure to people 
that need more structure. Clearly defining roles and hats can really help 
people get involved when they see a huge tasks and no obvious way that they fit 
into it.

What do y’all think?

— 
Rich Bowen
rbo...@rcbowen.com

[WG: Website] Proposal - Website working group

[Rich Bowen]

Proposed: Form a formal Website working group.

(I am aware that I haven’t defined “working group” yet, and I do, in fact, 
intend to propose a Working Groups Working Group which could possibly formalize 
what a working group looks like. I have some ideas, but no desire to go define 
it on my own.)

The Website WG would, obviously, be responsible for the maintenance of the 
website. I am aware that some folks think I’m just off doing that on my own, 
and that’s part of what I’m trying to avoid (see 
https://lists.apache.org/thread/nwvr28gq51c8v0wkqjv8xvvc2xqrtf03 for further 
commentary). I would like to gather a group of people who 1) care about it and 
2) are willing to do some of (NOT ALL) the work.

Specific things that I believe we should tackle include

* Long-term maintenance of the site. This involves regular audits, implementing 
metrics, and perhaps other things
* Reorg - this is a short-term task that I’ve been just doing on my own, which 
ensures it will never get done, and if it did, there may be some disagreement 
about how I did it.
* Deduplication - work closely with MarkPub to figure out the *right* place for 
certain information; work through the policy/best-practice dichotomy and ensure 
that we are *not* duplicating policy docs; Work on content on www.a.o 
<http://www.a.o/> that is closely related to content on community.a.o - which 
one is authoritative? Ensure that we don’t duplicate, contradict, or confuse.

There’s probably more.

I would hope that a WG would have regular checkins (could be email, Slack, 
Google Meet, I really don’t care, as long as everyone is engaging with the 
conversation.)

If you are interested in helping form this group, please speak up in this 
thread, and help us help one another.

— 
Rich Bowen
rbo...@rcbowen.com

Working groups

[Rich Bowen]

Hey, friends,

I’m recovering from FOSDEM, and going through my notes. I would like to propose 
a somewhat unformed idea that I would like to pursue for the next year or so - 
the idea of forming working groups here in ComDev, to pursue different tasks.

The reasoning for this is that, while I have eleventy million things that I 
want to accomplish under the umbrella of of ComDev, I have a tendency to just 
go do stuff myself, because building consensus is *hard*. That leads, 
consistently, to three outcomes:

• The stuff doesn’t actually get done, because my list is long
• Nobody else does it either, because that’s Rich’s project
• I get super frustrated that nobody is helping, even though I created that 
situation myself, and know that I created it.

This is hugely unproductive, and I would like to see if we can take a step 
towards making it easier for people to participate in narrowly defined ways 
that don’t seem quite as daunting as our current way of operating.

A working group would have a topic (“Website” is the first one that I’m likely 
to propose), a defined scope of work, and regular check-ins where progress is 
assessed, and narrowly defined action items can be volunteered for.

I love the way Kubernetes tackles this (see 
https://github.com/kubernetes/community for some of that) but we tend to 
believe, here at Apache, that this is too heavy on the structure side. I have 
come to think, over the past few months, that we need more structure, because 
our “just go jump in and do stuff!!” approach is hugely intimidating to 
beginners, and is no better than “figure it out yourself, I’m too busy” in 
terms of trying to engage new contributors.

Now, I know that this email is very fluffy and philosophical. I’ll be proposing 
a specific WG later this week, as soon as soon as I can write it up, and asking 
for folks to participate.

More, and more rambling, thoughts on this topic, here: 
https://drbacchus.com/the-many-hats-of-a-maintainer/ - if you’re interested.

— 
Rich Bowen
rbo...@rcbowen.com

VP Conferences changes

[Rich Bowen]

Fyi, effective yesterday, I have stepped down as VP conferences. The
responsibility for that role has passed to VP marketing, but communication
around conferences will still happen on the planners mailing list, as it
has for many years.

It's my hope to get a little more engaged on the side of the house, which,
of course, I've been trying to do for the last couple of years.

Rich

(NuttX) Re: Missing DOAP file

[Rich Bowen]

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

Requests for comdev membership

[Rich Bowen]

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

Rich

Re: [DRAFT] Email to all PMCs or Committers

[Rich Bowen]

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

[jira] [Commented] (COMDEV-423) svn pubsub fallen over on apachecon.com

[Rich Bowen (Jira)]

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

Rich Bowen commented on COMDEV-423:
---

 and, as I recall, was addressed almost immediately. Thank you for the garbage 
collection.

 

> svn pubsub fallen over on apachecon.com
> ---
>
> Key: COMDEV-423
> URL: https://issues.apache.org/jira/browse/COMDEV-423
> Project: Community Development
>  Issue Type: Task
>  Components: Website
>    Reporter: Rich Bowen
>Priority: Major
>
> Updates to svn are no longer being reflected on 
> [www.apachecon.com|http://www.apachecon.com/] 
> Can someone please kick svnpubsub? Thanks.



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

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

Final Reminder: Community Over Code call for presentations closing soon

[Rich Bowen]

[Note: You're receiving this email because you are subscribed to one or
more project dev@ mailing lists at the Apache Software Foundation.]

This is your final reminder that the Call for Presentations for
Community Over Code (formerly known as ApacheCon) is closing soon - on
Thursday, 13 July 2023 at 23:59:59 GMT.

https://communityovercode.org/call-for-presentations/

We are looking for talk proposals on all topics related to ASF projects
and open source software.

The event will be held in Halifax, Nova Scotia, Octiber 7th through
10th. More details about the event may be found on the event website at
https://communityovercode.org/

Rich, for the event planners

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

Re: Intent to recreate reporter.apache.org as a pipservice

[Rich Bowen]

+1 do it!

Rich


On Wed, Jun 28, 2023, 09:45 Daniel Gruno  wrote:

> Looks like there is a comdev-reporter.git which is an obsolete svn
> mirror. Any objections to removing that repository? History will still
> be present in subversion for the current reporter service.
>
> On 2023-06-28 13:27, Daniel Gruno wrote:
> > Hi, comdev folks,
> >
> > I have been pondering the current state of the reporter site that
> > projects may use for helping them generate and submit reports to the
> > board, and how we may improve upon it.
> >
> > One thing that sprung to mind today was to recreate it as a
> > PipService[1] which integrates much more smoothly with the general ASF
> > infrastructure and also allows developers to quickly spin up their own
> > local (contained) copy for testing.
> >
> > With these benefits in mind (along with some other generally helpful
> > improvements such as switching to an async framework on the backend), I
> > will be setting up a new repository for reporter.a.o as an "app".
> >
> > The repository will probably be called comdev-reporter.git unless
> > someone shouts very loudly and quickly :)
> >
> >
> > With regards,
> > Daniel.
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/INFRA/Pipservices
> >
> > -
> > 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: [PR] What makes a good report? (comdev-site)

[Rich Bowen]

In the past we have avoided linking to whimsy in public facing
documentation. It encourages people to dig to find what they can find.
Whimsy is *not* a place that we want people digging, IMHO, and if there's
alternate (there is) we should use it.

On Fri, Jun 23, 2023, 19:47 sebb  wrote:

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

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

[Rich Bowen]

On Fri, Jun 23, 2023, 06:10 rlenferink (via GitHub)  wrote:

>
> rlenferink commented on code in PR #125:
> URL: https://github.com/apache/comdev-site/pull/125#discussion_r1239637617
>
>
>
> Review Comment:
>Great addition! Should we maybe link to
> https://whimsy.apache.org/board/minutes/ if people want to easily select
> another project and have a look at their past reports ?
>

That's private but yeah I will link to the public version of that.

>