Re: Events calendar: help wanted

[sebb]

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.

Are all these needed?

On Fri, 19 Apr 2024 at 15:08, Bertrand Delacretaz
 wrote:
>
> On Fri, Apr 19, 2024 at 2:13 PM Rich Bowen  wrote:
> > ...I would *really* like to not have to edit ics files directly. That way 
> > lies madness...
>
> Indeed. If someone wants to take a look, Hugo (which is used for both
> the comdev and events websites) does support the generation of iCal
> files directly from markdown files representing events.
>
> https://github.com/raoulb/hugo-ical-templates-demo looks like a good
> example of that, except that it's using a complicated date format in
> the Markdown event files. But that can certainly be fixed.
>
> -Bertrand (really in "someone should" mode here, won't probably have
> time to help right now)
>
> -
> 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: Events calendar: help wanted

[sebb]

On Fri, 19 Apr 2024 at 12:08, Raphael Bircher  wrote:
>
> Hi Sebb
>
> On Fri, Apr 19, 2024 at 11:38 AM sebb  wrote:
>
> > On Fri, 19 Apr 2024 at 10:21, Raphael Bircher 
> > wrote:
> > >
> > > Hi Sebb
> > >
> > > On Fri, Apr 19, 2024 at 10:49 AM sebb  wrote:
> > >
> > >
> > > To put the data in a (JavaScript) generated Calendar like the one who was
> > > included via IFrame.
> >
> > But which data exactly? Where would the data be kept?
> >
> > The ICal file from google. We could fetch it directly from google or fetch
> it regularly on our server and include it from there into the JavaScript.

It would be trivial to fetch, but parsing it is non-trivial compared
with the JSON output.

> And would the page have the same functionality as the existing Google
> > calendar?
> >
>
> Not exactly the same I think

It does not have to look the same, but it should provide most of the
same functionality, otherwise why bother?

> >
> > If not, what would be different?
> >
> The main benefit would be, that we are able to move away from Google
> Calendar like Rich recommended earlier in the discussion

If we are to move away from Google Calendar, then the data should be
stored in a format that is easier to maintain and use.
ICS is not such a format.

> The JavaScript Calendar will only need a .ics files

Not an easy job, parsing ICS files.

> Regards, Raphael

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

Re: Events calendar: help wanted

[sebb]

On Fri, 19 Apr 2024 at 10:21, Raphael Bircher  wrote:
>
> Hi Sebb
>
> On Fri, Apr 19, 2024 at 10:49 AM sebb  wrote:
>
> > On Fri, 19 Apr 2024 at 09:23, Raphael Bircher 
> > wrote:
> > >
> > > Hi all
> > >
> > > On Fri, Apr 19, 2024 at 10:10 AM sebb  wrote:
> > >
> > > > On Fri, 19 Apr 2024 at 05:58, Dave Fisher  wrote:
> > > > >
> > > > > Hi Sebb,
> > > > >
> > > > > That is a a good approach! Can a similar approach be used with
> > > >
> > https://calendar.google.com/calendar/u/0/embed?src=nerseigospses068jd57bk5...@group.calendar.google.com=UTC=1
> > > >
> > > > If you are referring to the reference on the event/calendar.html page,
> > > > then no.
> > > >
> > > > As already noted, that is a dynamic page, whereas the front page only
> > > > shows the first 20 entries.
> > > >
> > > > Should we, (Vefko) now work on a JavaScript solution or not?
> >
> > Solution to what exactly?
> >
>
> To put the data in a (JavaScript) generated Calendar like the one who was
> included via IFrame.

But which data exactly? Where would the data be kept?

And would the page have the same functionality as the existing Google calendar?

If not, what would be different?

> Regards, Raphael

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

Re: Events calendar: help wanted

[sebb]

On Fri, 19 Apr 2024 at 09:23, Raphael Bircher  wrote:
>
> Hi all
>
> On Fri, Apr 19, 2024 at 10:10 AM sebb  wrote:
>
> > On Fri, 19 Apr 2024 at 05:58, Dave Fisher  wrote:
> > >
> > > Hi Sebb,
> > >
> > > That is a a good approach! Can a similar approach be used with
> > https://calendar.google.com/calendar/u/0/embed?src=nerseigospses068jd57bk5...@group.calendar.google.com=UTC=1
> >
> > If you are referring to the reference on the event/calendar.html page,
> > then no.
> >
> > As already noted, that is a dynamic page, whereas the front page only
> > shows the first 20 entries.
> >
> > Should we, (Vefko) now work on a JavaScript solution or not?

Solution to what exactly?

> Regards, Raphael

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

Re: Events calendar: help wanted

[sebb]

On Fri, 19 Apr 2024 at 05:58, Dave Fisher  wrote:
>
> Hi Sebb,
>
> That is a a good approach! Can a similar approach be used with 
> https://calendar.google.com/calendar/u/0/embed?src=nerseigospses068jd57bk5...@group.calendar.google.com=UTC=1

If you are referring to the reference on the event/calendar.html page, then no.

As already noted, that is a dynamic page, whereas the front page only
shows the first 20 entries.

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

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

Re: Events calendar: help wanted

[sebb]

OK, done.

https://community-calendar.staged.apache.org/ shows the calendar from
a local copy of the calendar data.
It should look exactly the same as the main site.

The plan is to fetch the calendar regularly using a GHA cron job
(daily should be sufficient; it can always be triggered manually if
necessary).

On Thu, 18 Apr 2024 at 15:44, sebb  wrote:
>
> Note that we don't have a DPA with Google, and it is extremely
> unlikely that we ever will, so the calendar on the main page also
> falls foul of the ASF privacy policy.
>
> Given that the data is static, it should not be too difficult to
> extract the data when the site is built.
>
> I'll try and look at that later.
>
> On Thu, 18 Apr 2024 at 15:27, Rich Bowen  wrote:
> >
> > > On Apr 18, 2024, at 10:25 AM, Raphael Bircher  
> > > wrote:
> > >
> > > Hi all
> > >
> > > Just a notice: before we install an other tool only to have a Ical
> > > function... confluence already has a calendar.
> >
> > Can you possibly say more about this, or perhaps provide a link?
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >

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

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

[Sebb (Jira)]

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

Sebb commented on COMDEV-544:
-

Note that there is a Mentor link under GSoC menu item on most pages

> 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

[sebb]

Note that we don't have a DPA with Google, and it is extremely
unlikely that we ever will, so the calendar on the main page also
falls foul of the ASF privacy policy.

Given that the data is static, it should not be too difficult to
extract the data when the site is built.

I'll try and look at that later.

On Thu, 18 Apr 2024 at 15:27, Rich Bowen  wrote:
>
> > On Apr 18, 2024, at 10:25 AM, Raphael Bircher  
> > wrote:
> >
> > Hi all
> >
> > Just a notice: before we install an other tool only to have a Ical
> > function... confluence already has a calendar.
>
> Can you possibly say more about this, or perhaps provide a link?
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[sebb]

It seems snoot.io has been abandoned.

I'll remove the references.

[1] https://lists.apache.org/thread/hv11bmodqhzhoqxq8ky72trtmwogc18q

On Wed, 17 Apr 2024 at 10:26, sebb  wrote:
>
> The page relies on the 3rd party provider snoot.io.
>
> This appears to have gone away; the hostname no longer resolves.
>
> On Wed, 17 Apr 2024 at 08:00, Pierre Smits  wrote:
> >
> > Hi all,
> >
> > it seems that https://projects.apache.org/statistics.html doesn't work
> > anymore as it does not show any statistics
> >
> > Met vriendelijke groet,
> >
> > Pierre

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

Re: Events calendar: help wanted

[sebb]

As a work-round, I have replaced the embedded calendar with a clickable link.
I agree it is not ideal, but at least it works.

Note that there is a fundamental difference between the summary
calendar on the main page and the full calendar, now no longer
embedded.

The former is a fixed list, with no user interaction, the latter
allows for scrolling by month etc.
I am not an expert, but I suspect it would be difficult to wrap that
in Javascript.

On Wed, 17 Apr 2024 at 17:39, Rich Bowen  wrote:
>
> 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
>

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

Re: Events calendar: help wanted

[sebb]

On Wed, 17 Apr 2024 at 17:01, Rich Bowen  wrote:
>
>
> > 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.

But better than no calendar, and better than exposing PII without permission.

> Either way, someone needs 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

[sebb]

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

On Wed, 17 Apr 2024 at 14:14, Rich Bowen  wrote:
>
> 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  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
>
>
>
>

-
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

[sebb]

The page relies on the 3rd party provider snoot.io.

This appears to have gone away; the hostname no longer resolves.

On Wed, 17 Apr 2024 at 08:00, Pierre Smits  wrote:
>
> Hi all,
>
> it seems that https://projects.apache.org/statistics.html doesn't work
> anymore as it does not show any statistics
>
> Met vriendelijke groet,
>
> Pierre

-
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

[sebb]

On Mon, 1 Apr 2024 at 15:08, sebb  wrote:
>
> On Mon, 1 Apr 2024 at 13:39, Rich Bowen  wrote:
> >
> > 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?
>
> README may be a hangover from a old build, which for some reason was
> not removed. Note: curl -I suggests the name is README.txt
> It will require Infra involvement to remove the README file, as that
> is done by pubsub from the asf-site branch (which does not have such a
> file)
>
> However you could try creating a temporary README.txt file in the main
> branch under static/, and when the README appears on the website, try
> deleting it from static.
> That might trigger deletion from the deployed site. If not, the
> ghostbusters will need to be called to get rid of the phantom file.

Looks like the temporary creation of the README.txt file has worked:

$ curl https://events.apache.org/README


404 Not Found

Not Found
The requested URL was not found on this server.


(you may need to refresh the browser cache to see this)

> If you are referring to README.md at
> https://github.com/apache/comdev-events-site, that is not part of the
> site build.
> It is intended to describe how the repo is used to build the site.
>
>
> Sebb

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

Re: Regarding the Apache Committee Report Helper Website

[sebb]

On Mon, 1 Apr 2024 at 15:44, Daniel Gruno  wrote:
>
> On 4/1/24 09:35, sebb wrote:
> > On Mon, 1 Apr 2024 at 15:14, Daniel Gruno  wrote:
> >>
> >> On 3/31/24 16:15, Dongjoon Hyun wrote:
> >>> Ya, it seems to happen at multiple projects.
> >>>
> >>> Like Apache ORC community, Apache Spark community report page is also 
> >>> missing JIRA/Commit/GitHub PR activities like the following.
> >>>
> >>> - https://reporter.apache.org/wizard/statistics?spark
> >>>
> >>> JIRA activity:
> >>> 0 issues opened in JIRA, past quarter (-100% change)
> >>> 0 issues closed in JIRA, past quarter (-100% change)
> >>>
> >>> Commit activity:
> >>> 0 commits in the past quarter (-100% decrease)
> >>> 0 code contributors in the past quarter (-100% change)
> >>>
> >>> GitHub PR activity:
> >>> 0 PRs opened on GitHub, past quarter (-100% change)
> >>> 0 PRs closed on GitHub, past quarter (-100% change)
> >>>
> >>> Dongjoon.
> >>
> >> The scanner had been stuck for a good while. I've cleared out the frozen
> >> processes, and hopefully the next rounds of scans should pick up some
> >> data again.
> >
> > Is there a way to check if the scanner is working?
> > And maybe send an alert if it is stuck?
>
> Some sort of cronjob that tests for whether a process has been running
> for more than N hours or days could probably do it, yeah. We tend to get
> rate-limited quite a lot due to the rather extreme size of our github
> org and number of jira spaces, so this is not a rare occurrence.

Or maybe the service could update something to show it is still working.
e.g. touch a file after every cycle.
This could then be added as a NodePing check.

> >
> >
> >>>
> >>> On 2024/03/31 08:46:20 sebb wrote:
> >>>> On Sun, 31 Mar 2024 at 09:38, Francis Chuang  
> >>>> wrote:
> >>>>>
> >>>>> I just checked for Calcite and the only stats missing for us is JIRA
> >>>>> activity. We have stats for everything else.
> >>>>>
> >>>>> Sheng Wu also raised this issue earlier today:
> >>>>> https://lists.apache.org/thread/2jn0m17276ny0l297nj5vfxtjsoksnz6
> >>>>>
> >>>>> I think there might be an issue with Whimsy's data collection.
> >>>>
> >>>> Whimsy is not involved in the data collection.
> >>>> It is done by Reporter and/or Kibble.
> >>>>
> >>>>> Francis
> >>>>>
> >>>>> On 31/03/2024 7:33 pm, William H. wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> Hope you are having a great Easter weekend.
> >>>>>>
> >>>>>> I am the Chair of Apache ORC and I was met with an error in the
> >>>>>> statistics section of the report helper website
> >>>>>> (https://reporter.apache.org/wizard/
> >>>>>> <https://reporter.apache.org/wizard/>) where it displayed the activity
> >>>>>> data for Jira, Commit, and GitHub as 0 for the past quarter when it
> >>>>>> shouldn't have. I was wondering if this is something that can be fixed.
> >>>>>> I have attached what it looks like below. Thank you in advance for your
> >>>>>> help.
> >>>>>>
> >>>>>> Bests,
> >>>>>> William Hyun
> >>>>>>
> >>>>>> Screenshot 2024-03-31 at 4.14.42 AM.png
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>>>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>>
> >>>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>
> -
> 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: Regarding the Apache Committee Report Helper Website

[sebb]

On Mon, 1 Apr 2024 at 15:14, Daniel Gruno  wrote:
>
> On 3/31/24 16:15, Dongjoon Hyun wrote:
> > Ya, it seems to happen at multiple projects.
> >
> > Like Apache ORC community, Apache Spark community report page is also 
> > missing JIRA/Commit/GitHub PR activities like the following.
> >
> > - https://reporter.apache.org/wizard/statistics?spark
> >
> > JIRA activity:
> > 0 issues opened in JIRA, past quarter (-100% change)
> > 0 issues closed in JIRA, past quarter (-100% change)
> >
> > Commit activity:
> > 0 commits in the past quarter (-100% decrease)
> > 0 code contributors in the past quarter (-100% change)
> >
> > GitHub PR activity:
> > 0 PRs opened on GitHub, past quarter (-100% change)
> > 0 PRs closed on GitHub, past quarter (-100% change)
> >
> > Dongjoon.
>
> The scanner had been stuck for a good while. I've cleared out the frozen
> processes, and hopefully the next rounds of scans should pick up some
> data again.

Is there a way to check if the scanner is working?
And maybe send an alert if it is stuck?


> >
> > On 2024/03/31 08:46:20 sebb wrote:
> >> On Sun, 31 Mar 2024 at 09:38, Francis Chuang  
> >> wrote:
> >>>
> >>> I just checked for Calcite and the only stats missing for us is JIRA
> >>> activity. We have stats for everything else.
> >>>
> >>> Sheng Wu also raised this issue earlier today:
> >>> https://lists.apache.org/thread/2jn0m17276ny0l297nj5vfxtjsoksnz6
> >>>
> >>> I think there might be an issue with Whimsy's data collection.
> >>
> >> Whimsy is not involved in the data collection.
> >> It is done by Reporter and/or Kibble.
> >>
> >>> Francis
> >>>
> >>> On 31/03/2024 7:33 pm, William H. wrote:
> >>>> Hello,
> >>>>
> >>>> Hope you are having a great Easter weekend.
> >>>>
> >>>> I am the Chair of Apache ORC and I was met with an error in the
> >>>> statistics section of the report helper website
> >>>> (https://reporter.apache.org/wizard/
> >>>> <https://reporter.apache.org/wizard/>) where it displayed the activity
> >>>> data for Jira, Commit, and GitHub as 0 for the past quarter when it
> >>>> shouldn't have. I was wondering if this is something that can be fixed.
> >>>> I have attached what it looks like below. Thank you in advance for your
> >>>> help.
> >>>>
> >>>> Bests,
> >>>> William Hyun
> >>>>
> >>>> Screenshot 2024-03-31 at 4.14.42 AM.png
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Conflicting information about event promotion

[sebb]

On Mon, 1 Apr 2024 at 13:39, Rich Bowen  wrote:
>
> 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?

README may be a hangover from a old build, which for some reason was
not removed. Note: curl -I suggests the name is README.txt
It will require Infra involvement to remove the README file, as that
is done by pubsub from the asf-site branch (which does not have such a
file)

However you could try creating a temporary README.txt file in the main
branch under static/, and when the README appears on the website, try
deleting it from static.
That might trigger deletion from the deployed site. If not, the
ghostbusters will need to be called to get rid of the phantom file.

If you are referring to README.md at
https://github.com/apache/comdev-events-site, that is not part of the
site build.
It is intended to describe how the repo is used to build the site.


Sebb

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

Re: Regarding the Apache Committee Report Helper Website

[sebb]

On Sun, 31 Mar 2024 at 09:38, Francis Chuang  wrote:
>
> I just checked for Calcite and the only stats missing for us is JIRA
> activity. We have stats for everything else.
>
> Sheng Wu also raised this issue earlier today:
> https://lists.apache.org/thread/2jn0m17276ny0l297nj5vfxtjsoksnz6
>
> I think there might be an issue with Whimsy's data collection.

Whimsy is not involved in the data collection.
It is done by Reporter and/or Kibble.

> Francis
>
> On 31/03/2024 7:33 pm, William H. wrote:
> > Hello,
> >
> > Hope you are having a great Easter weekend.
> >
> > I am the Chair of Apache ORC and I was met with an error in the
> > statistics section of the report helper website
> > (https://reporter.apache.org/wizard/
> > ) where it displayed the activity
> > data for Jira, Commit, and GitHub as 0 for the past quarter when it
> > shouldn't have. I was wondering if this is something that can be fixed.
> > I have attached what it looks like below. Thank you in advance for your
> > help.
> >
> > Bests,
> > William Hyun
> >
> > Screenshot 2024-03-31 at 4.14.42 AM.png
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[sebb]

On Sat, 23 Mar 2024 at 22:26, Christopher  wrote:
>
> On Sat, Mar 23, 2024 at 6:06 PM Gary Gregory  wrote:
> >
> > On Sat, Mar 23, 2024 at 4:59 PM Christopher  wrote:
> > >
> > > Delegate implies designated authority/responsibility, more than
> > > "maintainer" or "member", I think. The PMC role is delegated by the
> > > ASF Board (usually lazily, upon notice by existing PMC members). So, I
> > > think the word technically works here, but I won't argue that it's
> > > that much better than "PMC member", but I'll point out that "member"
> > > on its own has similar questions: member of what?
> >
> > Uh? Member of the PMC!
>
> Based on this response, I'm not sure I was clear. My point was that
> you could answer the question similarly for member as you could for
> delegate:
> 1. Member of what? the PMC
> 2. Delegate to what? the PMC
>
> It's not exactly identical... maybe "delegate" raises more
> questions... I don't know what other people think when they hear that
> word. My point was that it was kind of similar... if used on its own.
> But used in conjunction with "PMC", it's not really unclear: "PMC
> Member" vs. "PMC Delegate" seems pretty much equivalent to me. Perhaps
> that's not the case for others. I can only speak to what happens in my
> own brain.
>
> In any case, like I said, I'm not particularly fond of it either. So
> I'll leave it to others to debate. It was just a suggestion.

Note that there are also ASF members (and generic ASF committers).
It seems to me that any attempt to remove PMC from the name will
result in ambiguity.

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

Re: [WG: Badging] Tooling, reclaiming thread

[sebb]

On Wed, 20 Mar 2024 at 15:59, Paulo Motta  wrote:
>
> This is fair Sebb. I concede a separate namespace makes sense. This would
> also likely simplify the solution so we don't need to worry about clashes.
>
> Instead of overloading people.apache.org namespace which is associated with
> an ASF ID, I think it makes more sense to create a separate namespace
> instead, like contributors.apache.org/doejohn or badges.apache.org/doejohn .
>
> If the "doejohn" ASF ID handle is taken when the contributor "doejohn"
> becomes a committer, then it can just use something else as an ASF ID like
> "doejohn99" and call it a day.

And what if someone else later joins as an ASF committer with the id 'doejohn'?
What would their badge page be?

> In order to avoid contributors taking up existing ASF ID handles in the
> badging system which could create confusion, I think we would need to check
> if an ASF ID does not exist when creating the badging handle.
>
> Does this make sense?

It does not solve the fundamental issue.

The only way to solve it is to ensure that the bare ids inhabit a
different namespace from the ASF ids.

For example, badge ids could use Greek letters.
This is not a serious solution, but is a way to illustrate what I mean
about disjoint namespaces.


> On Wed, Mar 20, 2024 at 11:14 AM sebb  wrote:
>
> > On Wed, 20 Mar 2024 at 14:02, Paulo Motta  wrote:
> > >
> > > The ID reservation for 1 year is an optimistic "vote of confidence" that
> > > the contributor will remain active in the community and eventually
> > become a
> > > committer.
> >
> > There are already issues with 3rd party Wiki and Jira ids.
> > Let's not add another source of id clashes.
> >
> > I suggest using an id syntax that is not valid for ASF ids, then there
> > is no need to worry about clashes.
> > Yes, if a badge holder becomes an ASF committer they will have to
> > select a new id, but there could easily be a redirect from the old
> > badge page to the new one.
> >
> > Otherwise, not only will the badge ids have to be checked against ASF
> > ids, and Jira and Wiki, but those will also need to be checked against
> > badge ids.
> >
> > > Existing committers can enter a "waiting list" for reserved handles. If
> > the
> > > reserved handle owner is no longer active after 1 year, the handle is
> > > assigned to the first committer in the waiting list for that particular
> > > handle.
> > >
> > > On Wed, Mar 20, 2024 at 9:51 AM Paulo Motta  wrote:
> > >
> > > > Also we would need to have a way to detect malicious agents doing bogus
> > > > contributions to reserve handles. This is a separate issue that I would
> > > > prefer to keep out of this discussion for now.
> > > >
> > > > On Wed, 20 Mar 2024 at 10:47 Paulo Motta  wrote:
> > > >
> > > >> One question that could come up is:
> > > >>
> > > >> * what if someone does a single commit, and the ID is reserved and
> > > >> blocked for posterity
> > > >>
> > > >> We could add a 1 year TTL where the contributor would need to do
> > another
> > > >> commit within the next year to continue reserving the ID. This would
> > > >> incentivize people with reserved IDs to keep doing contributions to
> > keep
> > > >> their reserved handles.
> > > >>
> > > >> On Wed, 20 Mar 2024 at 10:36 Paulo Motta  wrote:
> > > >>
> > > >>> > Imagine you've been granted committer privileges but you can't pick
> > > >>> the ID you want because it has been "reserved" by a non-committer,
> > > >>>
> > > >>> This can not possibly happen, because the committer that was granted
> > > >>> committer privileges has already reserved its own ID when it became a
> > > >>> contributor in its first commit to any apache project. :)
> > > >>>
> > > >>> On Wed, Mar 20, 2024 at 9:25 AM Gary Gregory  > >
> > > >>> wrote:
> > > >>>
> > > >>>> I don't think we should allow IDs to be "reserved": Imagine you've
> > > >>>> been granted committer privileges but you can't pick the ID you want
> > > >>>> because it has been "reserved" by a non-committer, it seems
> > backward.
> > > >>>>
> > > >>>> Gary
> > > >>>>
&

Re: [WG: Badging] Tooling, reclaiming thread

[sebb]

On Wed, 20 Mar 2024 at 14:02, Paulo Motta  wrote:
>
> The ID reservation for 1 year is an optimistic "vote of confidence" that
> the contributor will remain active in the community and eventually become a
> committer.

There are already issues with 3rd party Wiki and Jira ids.
Let's not add another source of id clashes.

I suggest using an id syntax that is not valid for ASF ids, then there
is no need to worry about clashes.
Yes, if a badge holder becomes an ASF committer they will have to
select a new id, but there could easily be a redirect from the old
badge page to the new one.

Otherwise, not only will the badge ids have to be checked against ASF
ids, and Jira and Wiki, but those will also need to be checked against
badge ids.

> Existing committers can enter a "waiting list" for reserved handles. If the
> reserved handle owner is no longer active after 1 year, the handle is
> assigned to the first committer in the waiting list for that particular
> handle.
>
> On Wed, Mar 20, 2024 at 9:51 AM Paulo Motta  wrote:
>
> > Also we would need to have a way to detect malicious agents doing bogus
> > contributions to reserve handles. This is a separate issue that I would
> > prefer to keep out of this discussion for now.
> >
> > On Wed, 20 Mar 2024 at 10:47 Paulo Motta  wrote:
> >
> >> One question that could come up is:
> >>
> >> * what if someone does a single commit, and the ID is reserved and
> >> blocked for posterity
> >>
> >> We could add a 1 year TTL where the contributor would need to do another
> >> commit within the next year to continue reserving the ID. This would
> >> incentivize people with reserved IDs to keep doing contributions to keep
> >> their reserved handles.
> >>
> >> On Wed, 20 Mar 2024 at 10:36 Paulo Motta  wrote:
> >>
> >>> > Imagine you've been granted committer privileges but you can't pick
> >>> the ID you want because it has been "reserved" by a non-committer,
> >>>
> >>> This can not possibly happen, because the committer that was granted
> >>> committer privileges has already reserved its own ID when it became a
> >>> contributor in its first commit to any apache project. :)
> >>>
> >>> On Wed, Mar 20, 2024 at 9:25 AM Gary Gregory 
> >>> wrote:
> >>>
>  I don't think we should allow IDs to be "reserved": Imagine you've
>  been granted committer privileges but you can't pick the ID you want
>  because it has been "reserved" by a non-committer, it seems backward.
> 
>  Gary
> 
>  On Wed, Mar 20, 2024 at 8:37 AM Paulo Motta  wrote:
>  >
>  > This is right Claude. Essentially, the people.apache.org handle can
>  be seen
>  > as a “handle reservation” to a future ASF ID handle, that will be
>  granted
>  > when the contributor becomes a committee.
>  >
>  > So it’s basically a pre-ASF ID handle granted to contributors without
>  any
>  > privileges or login (except the people.apache.org auto-generated
>  > contributor page).
>  >
>  > On Wed, 20 Mar 2024 at 09:19 Claude Warren  wrote:
>  >
>  > > On Wed, Mar 20, 2024 at 12:55 AM Paulo Motta 
>  wrote:
>  > >
>  > > >
>  > > > 3. John Doe fills a simple form and selects the username
>  "doejohn", which
>  > > > is not an ASF id, but just a handle to a people.apache.org page.
>  If an
>  > > ASF
>  > > > id exists with the same name, then the request is rejected.
>  > > > 6. After some years of contributions, John Doe is invited to be a
>  > > committer
>  > > > of Apache Foo.
>  > > >   a. John can "convert" its username "doejohn" into an ASF ID, or
>  can
>  > > > choose another ASF ID handle when becoming a committer.
>  > > >   b. This kicks-off an update to people.apache.org/~doejohn to
>  change
>  > > the
>  > > > role from "ASF Contributor" to "Committer at Apache Foo"
>  > > >
>  > > >
>  > > The above 2 points indicate that our new committer registration
>  would
>  > > require that no handles used on people.apache.org be granted as an
>  ASF id.
>  > > Seems like we need a way to track the union of ASF Id and
>  > > people.apache.org
>  > > handles.
>  > >
>  > >
>  > > --
>  > > LinkedIn: http://www.linkedin.com/in/claudewarren
>  > >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>  For additional commands, e-mail: dev-h...@community.apache.org
> 
> 

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

Re: Reporter tool for board reports needs some love

[sebb]

On Tue, 19 Mar 2024 at 17:37, Andrew Musselman  wrote:
>
> I checked this revision in, inadvertently adding something I did a while
> back to make page loading faster as I recall. I can back that change out
> now.

Thanks.

I was about to reply to that commit to ask if that part of the change
was intended, as it was not mentioned in the log.

> $ svn ci -m"Adding updated information about what code is running behind
> the scenes for the reporter page (kibble)"
> SendingREADME.txt
> Sendingsite/js/addrelease.js
> Transmitting file data ..done
> Committing transaction...
> Committed revision 1916425.
>
> On Tue, Mar 19, 2024 at 10:24 AM Andrew Musselman  wrote:
>
> > I'll make that edit, thanks sebb.
> >
> > On Tue, Mar 19, 2024 at 10:11 AM sebb  wrote:
> >
> >> The linked README file is a bit out of date.
> >>
> >> Neither it nor the About page mention that many of the stats come from
> >> https://demo.kibble.apache.org/
> >>
> >> On Tue, 19 Mar 2024 at 16:25, Andrew Musselman  wrote:
> >> >
> >> > https://reporter.apache.org/about.html
> >> >
> >> > On Tue, Mar 19, 2024 at 8:56 AM tison  wrote:
> >> >
> >> > > May I ask where we host the reporter tool source code?
> >> > >
> >> > > Best,
> >> > > tison.
> >> > >
> >> > >
> >> > > Rich Bowen  于2024年3月19日周二 23:52写道：
> >> > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > > 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.
> >> > > >
> >> > > >
> >> > >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>

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

Re: Reporter tool for board reports needs some love

[sebb]

The linked README file is a bit out of date.

Neither it nor the About page mention that many of the stats come from
https://demo.kibble.apache.org/

On Tue, 19 Mar 2024 at 16:25, Andrew Musselman  wrote:
>
> https://reporter.apache.org/about.html
>
> On Tue, Mar 19, 2024 at 8:56 AM tison  wrote:
>
> > May I ask where we host the reporter tool source code?
> >
> > Best,
> > tison.
> >
> >
> > Rich Bowen  于2024年3月19日周二 23:52写道：
> >
> > >
> > >
> > >
> > > > 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.
> > >
> > >
> >

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

Re: [WG: Badging] Tooling

[sebb]

Badges may well cause some people to feel valued, but I think they can
be divisive.
What about people who don't 'earn' enough points to merit a badge?
Might that not cause them to feel undervalued?

The value of a person to an ASF project cannot be purely measured in
terms of the number of contributions; the quality of those
contributions is important.

Regarding encouraging PRs: it's not the number of PRs that matter,
it's the usefulness.
If number of PRs is to be used as a credit towards getting a badge,
maybe there should be a way to flag some PRs as undeserving.

On Sat, 9 Mar 2024 at 12:17, Paulo Motta  wrote:
>
> Apologies if the previous message sounded snarky - it was late and I
> impulsively cherry-picked some excerpts to comment without much second
> thought. :-)
>
> A more constructive attempt:
>
> 1. I like the principles of the Fedora badging program presented by Rich,
> and I think we should adopt them verbatim if they are openly licensed.
> 2. I think the "gamification" concern of Gary is actually a feature and not
> a bug - I think the goal of a badging program is to motivate people to
> contribute more to get more badges. If someone abuses the system to get
> badges without deserving them, then this is a problem that should be
> addressed if/when it arises.
> 3. Sebb does not see a point in badges and I also am not interested in
> earning them, but there are many people that do and this could be a good
> way to encourage contributions. To me, the target audiences of this program
> are primarily new contributors who are not yet committers, and secondarily
> seasoned contributors who like to earn or display badges. People who care
> less about badges don't need to receive them by just not signing up to the
> badging system as Rich said.
> 4. It looks like Rich has addressed Gary's privacy consideration but we can
> submit the proposal to ASF Privacy before being implemented for additional
> review.
> 5. I still think projects should opt-in for project-specific badges (ie.
> code contributions at project X). If the program is successful, projects
> will want to adopt it.
>
> > We should also have a simple way for people to propose new badges. Spot
> noted that the bottleneck with Fedora Badges has always been the design of
> the badge, not the lack of ideas.
>
> I agree but I think this may distract the initial implementation of the
> program. I think we should focus on one or a handful of carefully thought
> badges to start, and if they're proven effective then we could create a
> process to onboard new badges in the next iteration of the program.
>
> On Fri, Mar 8, 2024 at 11:21 PM Paulo Motta  wrote:
>
> > Nice discussion! A few comments:
> >
> > > I do not think that we need projects to opt in to this. Badges are not
> > aimed at projects. They are aimed at *people*.
> >
> > Disagree. Projects should have the autonomy to decide if they want to
> > adopt the ASF badging system for their contributions. I do not see why a
> > project would opt-out, but if they want to they should have this
> > prerrogative.
> >
> > > I am worried about gamification and a flood of PRs just to get badges.
> >
> > What’s the worry? A flood of PRs seems like a good thing for projects
> > needing contributions. 
> >
> > > Some people may not want badges; they should not be forced to have them
> > if they happen to meet the criteria.
> >
> > Badges need to be accepted by the awardee before being emitted.
> >
> > > Personally, I do not see the point of them.
> >
> > You are probably not the target audience for badges if you are a seasoned
> > contributor.
> >
> > > I wonder if there are there any privacy issue we should be able to
> > foresee?
> >
> > priv...@apache.org should determine if the privacy policy of the chosen
> > badging provider is acceptable, Badging WG members should not worry about
> > this.
> > On Fri, 8 Mar 2024 at 12:38 Gary Gregory  wrote:
> >
> >> Hi Rich,
> >>
> >> I don't have specific realistic concerns, I am trying to look ahead and
> >> avoid a "how didn't yiu guys think of THIS!" moment 
> >>
> >> Gary
> >>
> >> On Fri, Mar 8, 2024, 12:19 PM Rich Bowen  wrote:
> >>
> >> > > On Mar 8, 2024, at 12:09 PM, Gary D. Gregory 
> >> > wrote:
> >> > >
> >> > > Sure, badging can be fun and it sure seems popular on GitHub: I do
> >> like
> >> > my Mars 2020 Helicopter Mission badge (https://github.com/garydgregory/)
> >> !
> >> > >
> >> > > I wonder 

Re: [WG: Badging] Tooling

[sebb]

On Fri, 8 Mar 2024 at 15:44, Rich Bowen  wrote:
>
> 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.

That addresses my concern.

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

Good.

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

I was just expressing my opinion.

> —Rich

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

Re: [WG: Badging] Tooling

[sebb]

On Fri, 8 Mar 2024 at 15:15, Gary D. Gregory  wrote:
>
> > 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'm not sure about this. Opt-in would be fine with me. I am worried about 
> gamification and a flood of PRs just to get badges. I think experimenting 
> with a handful of projects first would be ok.

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.

Personally, I do not see the point of them.

> Gary
>
> On 2024/03/08 14:19:51 Rich Bowen wrote:
> >
> > > 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.
>
> -
> 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] Propose "why" folder that we will keep as "advisors" knowledge base [comdev-working-groups]

[sebb]

On Sat, 24 Feb 2024 at 00:53, justinmclean (via GitHub)  wrote:
>
>
> justinmclean commented on code in PR #16:
> URL: 
> https://github.com/apache/comdev-working-groups/pull/16#discussion_r1501297317
>
>
> ##
> wg-advisors/why/why_release_process.md:
> ##
> @@ -0,0 +1,30 @@
> +# Release process
> +
> +## Summary
> +
> +ASF project release software following a well defined process involving PMC 
> members voting on release
> +candidates, publishing the artifacts in the ASF distribution system, and 
> announcing the release to the
> +community.
> +
> +## Links to relevant documents
> +
> +* [Release Policy](https://www.apache.org/dev/release.html)
> +* [Release Distribution 
> Policy](https://www.apache.org/dev/release-distribution.html)
> +
> +## Why are we doing it?
> +
> +We are doing it because this is what the ASF is doing. ASF delivers 
> "Software for the public good"
> +and the act of releasing software is a key part of that. The process is 
> designed to ensure that the
> +software is properly vetted and that the community is aware of the release 
> and that the process of
> +releasing software is transparent, open and secure. Releasing the software 
> is a Legal Act of the
> +Foundation and it has consequences for the Foundation as software released 
> by the Foundation is
> +the main way the Foundation interacts with the public and can be hold 
> accountable for the software
> +it releases.
> +
> +## Is it mandatory and what are conditions?
> +
> +The process is mandatory for all ASF projects. The process is the same for 
> all projects. This
> +
> +## Are there variations for different projects?
> +
> +Not really. The process is the same for all projects.
>
> Review Comment:
>There is some variation: a few projects use super majority voting, some 
> have voters sign releases, the length of time a vote is open often varies, 
> some projects consider the RM as an implicit +1, not all projects announce 
> releases, and there are probably a few things I've forgotten about.

An implicit +1 from the RM is not something that should be encouraged.

Also the minimum length of time for voting is 72 hours, except for
urgent security-related releases.

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

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

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

[sebb]

On Thu, 22 Feb 2024 at 00:08, tison  wrote:
>
> It's currently a brand new branch. You can check it in the repo.

OK, great. It seems I was misled by the summary page, which says:

"This branch is 5 commits ahead of, 34 commits behind master."

To me, that definitely implies a relationship. Very confusing.

However, try a compare, and it says: "master and docusaurus are
entirely different commit histories."

> Best,
> tison.
>
>
> sebb 于2024年2月22日 周四01:11写道：
>
> > On Wed, 21 Feb 2024 at 09:25, tison  wrote:
> > >
> > > Hi sebb,
> > >
> > > Your comments sound like back to the switching default branch solution (a
> > > new branch with history only adding the README becomes the default).
> >
> > I am saying that if the 3 branch solution is adopted the docusaurus
> > branch should be created as a new branch.
> >
> > > Or you prefer other ways to the same repo direction.
> > >
> > > Also is it possible we go back to the COMDEV dedicated thread so that
> > > people can easily follow the context? If we agree, the context here can
> > be
> > > brought there.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > sebb 于2024年2月21日 周三16:27写道：
> > >
> > > > On Wed, 21 Feb 2024 at 00:28, tison  wrote:
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > > One approach is to find good examples of each build technique. If
> > you
> > > > look back at older projects you will see various historical waves of
> > > > technique.
> > > > >
> > > > > I agree, and that's why I'd prefer a multi branches solution with a
> > > > > default branch containing README for redirects.
> > > >
> > > > However, if a repo is shared in this way, such disjoint branches
> > > > should be initially created as empty orphans.
> > > > Replacing all the files with different ones makes for a confusing
> > history.
> > > >
> > > > > From another perspective, it's still valuable to provide a template
> > > > > for new podlings to get started _now_, and if someone (in this case,
> > > > > it's me) volunteers to provide one for help, there is no reason we
> > > > > reject it by the tech will fade _years later_.
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > Dave Fisher  于2024年2月21日周三 08:17写道：
> > > > > >
> > > > > > Hi Tison,
> > > > > >
> > > > > > I’m following along. Infrastructure has a Pelican template site
> > that
> > > > is out of date: https://github.com/apache/template-site/
> > > > > >
> > > > > > One approach is to find good examples of each build technique. If
> > you
> > > > look back at older projects you will see various historical waves of
> > > > technique.
> > > > > >
> > > > > > Best,
> > > > > > Dave
> > > > > >
> > > > > > > On Feb 20, 2024, at 3:48 PM, tison  wrote:
> > > > > > >
> > > > > > > Hi Dave,
> > > > > > >
> > > > > > > Thanks for picking up this commit. You may join the discussion at
> > > > [1].
> > > > > > >
> > > > > > > I have all the permission to follow what I want. But since
> > > > > > > apache-website-template is technically a foundation-wise repo
> > and I'm
> > > > > > > a newcomer here, I'd like to listen to people's opinions before
> > > > moving
> > > > > > > forward; especially there can be some arguments.
> > > > > > >
> > > > > > > Best,
> > > > > > > tison.
> > > > > > >
> > > > > > > [1]
> > https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8
> > > > > > >
> > > > > > > Dave Fisher  于2024年2月21日周三 02:35写道：
> > > > > > >>
> > > > > > >> From the commit email it looks like this repository belongs to
> > the
> > > > Incubator.
> > > > > > >>
> > > > > > >>> On Feb 14, 2024, at 2:27 AM, ti...@ap

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

[sebb]

On Wed, 21 Feb 2024 at 09:25, tison  wrote:
>
> Hi sebb,
>
> Your comments sound like back to the switching default branch solution (a
> new branch with history only adding the README becomes the default).

I am saying that if the 3 branch solution is adopted the docusaurus
branch should be created as a new branch.

> Or you prefer other ways to the same repo direction.
>
> Also is it possible we go back to the COMDEV dedicated thread so that
> people can easily follow the context? If we agree, the context here can be
> brought there.
>
> Best,
> tison.
>
>
> sebb 于2024年2月21日 周三16:27写道：
>
> > On Wed, 21 Feb 2024 at 00:28, tison  wrote:
> > >
> > > Hi Dave,
> > >
> > > > One approach is to find good examples of each build technique. If you
> > look back at older projects you will see various historical waves of
> > technique.
> > >
> > > I agree, and that's why I'd prefer a multi branches solution with a
> > > default branch containing README for redirects.
> >
> > However, if a repo is shared in this way, such disjoint branches
> > should be initially created as empty orphans.
> > Replacing all the files with different ones makes for a confusing history.
> >
> > > From another perspective, it's still valuable to provide a template
> > > for new podlings to get started _now_, and if someone (in this case,
> > > it's me) volunteers to provide one for help, there is no reason we
> > > reject it by the tech will fade _years later_.
> > >
> > > Best,
> > > tison.
> > >
> > > Dave Fisher  于2024年2月21日周三 08:17写道：
> > > >
> > > > Hi Tison,
> > > >
> > > > I’m following along. Infrastructure has a Pelican template site that
> > is out of date: https://github.com/apache/template-site/
> > > >
> > > > One approach is to find good examples of each build technique. If you
> > look back at older projects you will see various historical waves of
> > technique.
> > > >
> > > > Best,
> > > > Dave
> > > >
> > > > > On Feb 20, 2024, at 3:48 PM, tison  wrote:
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > Thanks for picking up this commit. You may join the discussion at
> > [1].
> > > > >
> > > > > I have all the permission to follow what I want. But since
> > > > > apache-website-template is technically a foundation-wise repo and I'm
> > > > > a newcomer here, I'd like to listen to people's opinions before
> > moving
> > > > > forward; especially there can be some arguments.
> > > > >
> > > > > Best,
> > > > > tison.
> > > > >
> > > > > [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8
> > > > >
> > > > > Dave Fisher  于2024年2月21日周三 02:35写道：
> > > > >>
> > > > >> From the commit email it looks like this repository belongs to the
> > Incubator.
> > > > >>
> > > > >>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote:
> > > > >>>
> > > > >>> This is an automated email from the ASF dual-hosted git repository.
> > > > >>>
> > > > >>> tison pushed a change to branch jekyll
> > > > >>> in repository
> > https://gitbox.apache.org/repos/asf/apache-website-template.git
> > > > >>>
> > > > >>>
> > > > >>> at f2f8a9e  Update download page template
> > > > >>>
> > > > >>> No new revisions were added by this update.
> > > > >>>
> > > > >>>
> > > > >>>
> > -
> > > > >>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> > > > >>> For additional commands, e-mail: cvs-h...@incubator.apache.org
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > > > >>
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > > For additional commands, e-mail: general-h...@incubator.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

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

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

[sebb]

On Wed, 21 Feb 2024 at 00:28, tison  wrote:
>
> Hi Dave,
>
> > One approach is to find good examples of each build technique. If you look 
> > back at older projects you will see various historical waves of technique.
>
> I agree, and that's why I'd prefer a multi branches solution with a
> default branch containing README for redirects.

However, if a repo is shared in this way, such disjoint branches
should be initially created as empty orphans.
Replacing all the files with different ones makes for a confusing history.

> From another perspective, it's still valuable to provide a template
> for new podlings to get started _now_, and if someone (in this case,
> it's me) volunteers to provide one for help, there is no reason we
> reject it by the tech will fade _years later_.
>
> Best,
> tison.
>
> Dave Fisher  于2024年2月21日周三 08:17写道：
> >
> > Hi Tison,
> >
> > I’m following along. Infrastructure has a Pelican template site that is out 
> > of date: https://github.com/apache/template-site/
> >
> > One approach is to find good examples of each build technique. If you look 
> > back at older projects you will see various historical waves of technique.
> >
> > Best,
> > Dave
> >
> > > On Feb 20, 2024, at 3:48 PM, tison  wrote:
> > >
> > > Hi Dave,
> > >
> > > Thanks for picking up this commit. You may join the discussion at [1].
> > >
> > > I have all the permission to follow what I want. But since
> > > apache-website-template is technically a foundation-wise repo and I'm
> > > a newcomer here, I'd like to listen to people's opinions before moving
> > > forward; especially there can be some arguments.
> > >
> > > Best,
> > > tison.
> > >
> > > [1] https://lists.apache.org/thread/tvry49gdclqqdtdcgk0x9hnl18vlxnm8
> > >
> > > Dave Fisher  于2024年2月21日周三 02:35写道：
> > >>
> > >> From the commit email it looks like this repository belongs to the 
> > >> Incubator.
> > >>
> > >>> On Feb 14, 2024, at 2:27 AM, ti...@apache.org wrote:
> > >>>
> > >>> This is an automated email from the ASF dual-hosted git repository.
> > >>>
> > >>> tison pushed a change to branch jekyll
> > >>> in repository 
> > >>> https://gitbox.apache.org/repos/asf/apache-website-template.git
> > >>>
> > >>>
> > >>> at f2f8a9e  Update download page template
> > >>>
> > >>> No new revisions were added by this update.
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> > >>> For additional commands, e-mail: cvs-h...@incubator.apache.org
> > >>>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [WG: Sharpeners] Propose: milder name

[sebb]

+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

[WG: Sharpeners] Propose: milder name

[sebb]

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: [REQUEST] Create apache/community GitHub Repo (WAS: Working groups working group)

[sebb]

Why not migrate the SVN repo to Git?
Is there any need to keep the info in SVN?

On Mon, 12 Feb 2024 at 15:14, 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.
>
> What do you think?
>
> [1] https://issues.apache.org/jira/browse/INFRA-25482
> [2] https://gitbox.apache.org/boxer/?action=newrepo
>
> Best,
> tison.
>
> tison  于2024年2月8日周四 22:49写道：
> >
> > >> I just want to make these things more discoverable
> > > please feel free to jump in and make an infra ticket to move/mirror that 
> > > to GitHub
> >
> > If discoverable is an object, I suggest we use GitHub, at least as a
> > mirror and accept issues and discussions. It's also easier to share
> > over social media.
> >
> > I created the ticket that you can check [1].
> >
> > Best,
> > tison.
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-25482
> >
> > Rich Bowen  于2024年2月8日周四 22:32写道：
> > >
> > >
> > > > 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  for 
> > > > stuff like this, to mirror 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
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

[jira] [Created] (COMDEV-539) chi report disagrees with mail stats

[Sebb (Jira)]

Sebb created COMDEV-539:
---

 Summary: chi report disagrees with mail stats
 Key: COMDEV-539
 URL: https://issues.apache.org/jira/browse/COMDEV-539
 Project: Community Development
  Issue Type: Bug
  Components: Reporter Tool
Reporter: Sebb


The chi analysis disagrees with the mailing list stats for several projects.

e.g. chi score explanation says "No email sent to ANY ML in the past quarter" 
but the mailing list trends show that there were emails in the last quarter.

This occurs for several projects.



--
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: [website] how to add an “edit in GitHub” link?

[sebb]

On Mon, 27 Nov 2023 at 20:27, Roy Lenferink  wrote:
>
> Op ma 27 nov 2023 om 20:26 schreef sebb 
>
> > On Mon, 27 Nov 2023 at 14:20, Bertrand Delacretaz
> >  wrote:
> > >
> > > Hi,
> > >
> > > I'd like to add an "edit in GitHub" link to the pages of
> > > https://community.apache.org/ , like we have in Sling [1].
> >
> > Personally, I would rather the link was to the page source in the comdev
> > repo.
> > Otherwise one is forced to clone the repo before one can see how easy
> > the change is likely to be.
>
>
> You mean something like the following?
>
> https://celix.apache.org/contributing/releasing.html

No, because that forces one to clone the site up-front.

Providing a link to the source page does mean an extra click to edit
the file, but it means one can still provide a patch if one does not
wish to subscribe to GH.

> The source for how Celix handles that can be found here:
>
> https://github.com/apache/celix-site/blob/master/layouts/_default/baseof.html#L50
>
>
>
> >
> > > But I don't know how to do it with Hugo - before I dig too deep, does
> > > someone have an example?
> >
> > Looks like the following can be used in the baseof.html template file
> > as the URL target of a link:
> >
> > https://github.com/apache/comdev-site/blob/main/source/{{ .Page.File }}
> >
> > This can be nested in the conditional:
> >
> > {{ if .IsPage }}   {{ end }}
> >
> > > For some pages like [2] which are generated instead of being backed by
> > > a Markdown file, we'd need to either link to the repository home, or
> > > add no link.
> > >
> > > -Bertrand
> > >
> > > [1] https://sling.apache.org/documentation/development.html (at the
> > > bottom, "this page can be edited...")
> > > [2] https://community.apache.org/tags.html
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >

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

Re: [website] how to add an “edit in GitHub” link?

[sebb]

On Mon, 27 Nov 2023 at 14:20, Bertrand Delacretaz
 wrote:
>
> Hi,
>
> I'd like to add an "edit in GitHub" link to the pages of
> https://community.apache.org/ , like we have in Sling [1].

Personally, I would rather the link was to the page source in the comdev repo.
Otherwise one is forced to clone the repo before one can see how easy
the change is likely to be.

> But I don't know how to do it with Hugo - before I dig too deep, does
> someone have an example?

Looks like the following can be used in the baseof.html template file
as the URL target of a link:

https://github.com/apache/comdev-site/blob/main/source/{{ .Page.File }}

This can be nested in the conditional:

{{ if .IsPage }}   {{ end }}

> For some pages like [2] which are generated instead of being backed by
> a Markdown file, we'd need to either link to the repository home, or
> add no link.
>
> -Bertrand
>
> [1] https://sling.apache.org/documentation/development.html (at the
> bottom, "this page can be edited...")
> [2] https://community.apache.org/tags.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

[jira] [Resolved] (COMDEV-531) Unable to submit report via reporter.a.org

[Sebb (Jira)]

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

Sebb resolved COMDEV-531.
-
Resolution: Fixed

> Unable to submit report via reporter.a.org
> --
>
> Key: COMDEV-531
> URL: https://issues.apache.org/jira/browse/COMDEV-531
> Project: Community Development
>  Issue Type: Bug
>Reporter: Philipp Ottlinger
>Priority: Major
>
> When I tried to file the Creadur report I was able to properly edit the 
> report, but when hitting "Publish via Whimsy" all I get is:
> "Something went wrong, and we couldn't publish your report.
> Please check with the Whimsy tool to see if there is already a report posted!"
> Not sure what else to add ... thus so unspecific.



--
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: ASF Event link broken?

[sebb]

On Wed, 1 Nov 2023 at 20:08, Daniel Gruno  wrote:
>
> On 2023-11-01 12:55, sebb wrote:
> > On Wed, 1 Nov 2023 at 16:59, Daniel Gruno  wrote:
> >>
> >> On 2023-10-31 14:42, sebb wrote:
> >>> On Tue, 31 Oct 2023 at 17:34, Daniel Gruno  wrote:
> >>>>
> >>>> On 2023-10-31 12:27, Daniel Gruno wrote:
> >>>>> On 2023-10-31 12:17, sebb wrote:
> >>>>>> On Tue, 31 Oct 2023 at 09:57, sebb  wrote:
> >>>>>>>
> >>>>>>> Try adding .html at the end. I think that used to be done
> >>>>>>> automatically, but no longer seems to be happening.
> >>>>>>
> >>>>>> I checked, and it did work previously:
> >>>>>> https://www-previous.staged.apache.org/events/current-event
> >>>>>> (note that the redirect works, but goes to the old site, so please
> >>>>>> ignore the final contents)
> >>>>>
> >>>>> There is a redirect in place, but it's not being honored because
> >>>>> 'FileInfo' type directives (redirects) are not allowed on www.a.o via
> >>>>> .htaccess. This should be addressed instead, which I am doing now.
> >>>
> >>> However other redirects were working.
> >>
> >> Yes, it turned out to be a sort of red herring. The root cause is that a
> >> .htaccess file works with its directory as the root for URIs, so in this
> >> case, /events/foo won't be matched, but /foo will, as /events is
> >> implied.
> >
> > Sorry, but that does not appear to be correct.
> > If it is the case, why is it that the .htaccess file under /dev is working?
> >
> > All its entries have a /dev prefix:
> > https://github.com/apache/www-site/blob/main/content/dev/.htaccess
> >
> >> The .htaccess has been sorted out, and redirects are working again.
> >
> > Yes, by reverting the change that dropped the /events path segment.
> >
> > Redirection of current-event (without .html) needs the corresponding
> > file to be present; I don't know why that is.
> >
>
> It gets complicated. The revert you did only works if the current-event
> file (without the .html suffix) exists.
Agreed.
> If it does not, then the
> previous .htaccess directive works, but the reverted state does not.

No, the version without the leading /events path segment does not work at all.
See below.

> If
> the file IS there, then the reverted state works, but the one I made
> doesn't work. Without spending too much time on debugging this, I still
> believe centralizing the redirects will help with whatever overrides are
> causing this confusion. We have one server config for the virtual host
> PLUS two .htaccess files vying for attention here. Confusion ensues.

There are more than 2 htaccess files.
They use absolute paths relative to the website root, not the htaccess file.

I have set up a preview site: preview/htaccess.
This is a copy of the main site, with a couple of adjustments:

/dev/.htaccess:
https://github.com/apache/www-site/blob/1d1fcc0a1050583b200fb6528edc6dfc6d444ffc/content/dev/.htaccess#L21
- removed /dev prefix from committers[.html]
These both now report 404

/events/.htaccess:
https://github.com/apache/www-site/blob/1d1fcc0a1050583b200fb6528edc6dfc6d444ffc/content/events/.htaccess#L9
- added /test1[.html] - 404s
- added /events/test2[.html] - these work fine

I think these prove that htaccess redirects require the full path from
the website root, not the htaccess file.

Feel free to add further tests.

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

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

Re: ASF Event link broken?

[sebb]

On Wed, 1 Nov 2023 at 16:59, Daniel Gruno  wrote:
>
> On 2023-10-31 14:42, sebb wrote:
> > On Tue, 31 Oct 2023 at 17:34, Daniel Gruno  wrote:
> >>
> >> On 2023-10-31 12:27, Daniel Gruno wrote:
> >>> On 2023-10-31 12:17, sebb wrote:
> >>>> On Tue, 31 Oct 2023 at 09:57, sebb  wrote:
> >>>>>
> >>>>> Try adding .html at the end. I think that used to be done
> >>>>> automatically, but no longer seems to be happening.
> >>>>
> >>>> I checked, and it did work previously:
> >>>> https://www-previous.staged.apache.org/events/current-event
> >>>> (note that the redirect works, but goes to the old site, so please
> >>>> ignore the final contents)
> >>>
> >>> There is a redirect in place, but it's not being honored because
> >>> 'FileInfo' type directives (redirects) are not allowed on www.a.o via
> >>> .htaccess. This should be addressed instead, which I am doing now.
> >
> > However other redirects were working.
>
> Yes, it turned out to be a sort of red herring. The root cause is that a
> .htaccess file works with its directory as the root for URIs, so in this
> case, /events/foo won't be matched, but /foo will, as /events is
> implied.

Sorry, but that does not appear to be correct.
If it is the case, why is it that the .htaccess file under /dev is working?

All its entries have a /dev prefix:
https://github.com/apache/www-site/blob/main/content/dev/.htaccess

> The .htaccess has been sorted out, and redirects are working again.

Yes, by reverting the change that dropped the /events path segment.

Redirection of current-event (without .html) needs the corresponding
file to be present; I don't know why that is.

> >
> >> There seems to be conflicting directives in the mix, which are causing
> >> issues (the events/.htaccess is not being honored at all).
> >
> > I don't think that is correct, as the redirect for current-events.html
> > is being honoured from that file.
> > Besides, the redirect does work when there is a dummy 'current-events' file.
> > See the preview/currentevent staging site.
> >
> >> Some cleanup
> >> should preferably be done, moving these redirects into one unified
> >> .htaccess file or rewrite map at the root.
> >
> > Perhaps, but that is a separate issue.
> >
> >>>
> >>>
> >>>>
> >>>> I've submitted a PR to fix it going forward:
> >>>> https://github.com/apache/www-site/pull/323
> >>>>
> >>>>> Note that a new method is now recommended, see:
> >>>>>
> >>>>> https://www.apache.org/events/README.txt
> >>>>> (as linked from the Whimsy page)
> >>>>>
> >>>>> On Tue, 31 Oct 2023 at 08:53, tison  wrote:
> >>>>>>
> >>>>>> Whimsy guides podlings to add a link to
> >>>>>> https://www.apache.org/events/current-event.
> >>>>>>
> >>>>>> But this page is now 404. Is it moved or what we should update it with?
> >>>>>>
> >>>>>> Best,
> >>>>>> tison.
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: ASF Event link broken?

[sebb]

FTR, the problem has been fixed - both current-event.html and
current-event now redirect the CoC site.

On Tue, 31 Oct 2023 at 19:42, sebb  wrote:
>
> On Tue, 31 Oct 2023 at 17:34, Daniel Gruno  wrote:
> >
> > On 2023-10-31 12:27, Daniel Gruno wrote:
> > > On 2023-10-31 12:17, sebb wrote:
> > >> On Tue, 31 Oct 2023 at 09:57, sebb  wrote:
> > >>>
> > >>> Try adding .html at the end. I think that used to be done
> > >>> automatically, but no longer seems to be happening.
> > >>
> > >> I checked, and it did work previously:
> > >> https://www-previous.staged.apache.org/events/current-event
> > >> (note that the redirect works, but goes to the old site, so please
> > >> ignore the final contents)
> > >
> > > There is a redirect in place, but it's not being honored because
> > > 'FileInfo' type directives (redirects) are not allowed on www.a.o via
> > > .htaccess. This should be addressed instead, which I am doing now.
>
> However other redirects were working.
>
> > There seems to be conflicting directives in the mix, which are causing
> > issues (the events/.htaccess is not being honored at all).
>
> I don't think that is correct, as the redirect for current-events.html
> is being honoured from that file.
> Besides, the redirect does work when there is a dummy 'current-events' file.
> See the preview/currentevent staging site.
>
> > Some cleanup
> > should preferably be done, moving these redirects into one unified
> > .htaccess file or rewrite map at the root.
>
> Perhaps, but that is a separate issue.
>
> > >
> > >
> > >>
> > >> I've submitted a PR to fix it going forward:
> > >> https://github.com/apache/www-site/pull/323
> > >>
> > >>> Note that a new method is now recommended, see:
> > >>>
> > >>> https://www.apache.org/events/README.txt
> > >>> (as linked from the Whimsy page)
> > >>>
> > >>> On Tue, 31 Oct 2023 at 08:53, tison  wrote:
> > >>>>
> > >>>> Whimsy guides podlings to add a link to
> > >>>> https://www.apache.org/events/current-event.
> > >>>>
> > >>>> But this page is now 404. Is it moved or what we should update it with?
> > >>>>
> > >>>> Best,
> > >>>> tison.
> > >>
> > >> -
> > >> 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: ASF Event link broken?

[sebb]

On Tue, 31 Oct 2023 at 17:34, Daniel Gruno  wrote:
>
> On 2023-10-31 12:27, Daniel Gruno wrote:
> > On 2023-10-31 12:17, sebb wrote:
> >> On Tue, 31 Oct 2023 at 09:57, sebb  wrote:
> >>>
> >>> Try adding .html at the end. I think that used to be done
> >>> automatically, but no longer seems to be happening.
> >>
> >> I checked, and it did work previously:
> >> https://www-previous.staged.apache.org/events/current-event
> >> (note that the redirect works, but goes to the old site, so please
> >> ignore the final contents)
> >
> > There is a redirect in place, but it's not being honored because
> > 'FileInfo' type directives (redirects) are not allowed on www.a.o via
> > .htaccess. This should be addressed instead, which I am doing now.

However other redirects were working.

> There seems to be conflicting directives in the mix, which are causing
> issues (the events/.htaccess is not being honored at all).

I don't think that is correct, as the redirect for current-events.html
is being honoured from that file.
Besides, the redirect does work when there is a dummy 'current-events' file.
See the preview/currentevent staging site.

> Some cleanup
> should preferably be done, moving these redirects into one unified
> .htaccess file or rewrite map at the root.

Perhaps, but that is a separate issue.

> >
> >
> >>
> >> I've submitted a PR to fix it going forward:
> >> https://github.com/apache/www-site/pull/323
> >>
> >>> Note that a new method is now recommended, see:
> >>>
> >>> https://www.apache.org/events/README.txt
> >>> (as linked from the Whimsy page)
> >>>
> >>> On Tue, 31 Oct 2023 at 08:53, tison  wrote:
> >>>>
> >>>> Whimsy guides podlings to add a link to
> >>>> https://www.apache.org/events/current-event.
> >>>>
> >>>> But this page is now 404. Is it moved or what we should update it with?
> >>>>
> >>>> Best,
> >>>> tison.
> >>
> >> -
> >> 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: ASF Event link broken?

[sebb]

On Tue, 31 Oct 2023 at 09:57, sebb  wrote:
>
> Try adding .html at the end. I think that used to be done
> automatically, but no longer seems to be happening.

I checked, and it did work previously:
https://www-previous.staged.apache.org/events/current-event
(note that the redirect works, but goes to the old site, so please
ignore the final contents)

I've submitted a PR to fix it going forward:
https://github.com/apache/www-site/pull/323

> Note that a new method is now recommended, see:
>
> https://www.apache.org/events/README.txt
> (as linked from the Whimsy page)
>
> On Tue, 31 Oct 2023 at 08:53, tison  wrote:
> >
> > Whimsy guides podlings to add a link to
> > https://www.apache.org/events/current-event.
> >
> > But this page is now 404. Is it moved or what we should update it with?
> >
> > Best,
> > tison.

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

Re: ASF Event link broken?

[sebb]

Try adding .html at the end. I think that used to be done
automatically, but no longer seems to be happening.

Note that a new method is now recommended, see:

https://www.apache.org/events/README.txt
(as linked from the Whimsy page)

On Tue, 31 Oct 2023 at 08:53, tison  wrote:
>
> Whimsy guides podlings to add a link to
> https://www.apache.org/events/current-event.
>
> But this page is now 404. Is it moved or what we should update it with?
>
> Best,
> tison.

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

[jira] [Comment Edited] (COMDEV-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb edited comment on COMDEV-538 at 10/18/23 4:43 PM:
---

Thanks for confirming it has been fixed.
Interesting re the server behaviour.
This could explain the unexpected caching of data by the browser.
 
In the case of Safari, it serves much of the content from cache. This includes 
the JSON data that is displayed. Need to look into how to tell Safari to expire 
content.


was (Author: s...@apache.org):
Thanks for confirming it has been fixed.
Interesting re the server behaviour.
This could explain the unexpected caching of data by the browser.


> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb commented on COMDEV-538:
-

Thanks for confirming it has been fixed.
Interesting re the server behaviour.
This could explain the unexpected caching of data by the browser.


> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb resolved COMDEV-538.
-
Resolution: Fixed

> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb commented on COMDEV-538:
-

Looks OK to me.
Make sure you refresh your browser cache (or try a different browser).
If using Safari, try Command+Option+E, then Command+R.

> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb commented on COMDEV-538:
-

There was a bug in the code that fetched the data; now fixed.

> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb resolved COMDEV-538.
-
Resolution: Information Provided

> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Improvement
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-538) PMC information outdated at https://projects.apache.org/committee.html?maven

[Sebb (Jira)]

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

Sebb commented on COMDEV-538:
-

The jobs are run daily overnight

> PMC information outdated at https://projects.apache.org/committee.html?maven
> 
>
> Key: COMDEV-538
> URL: https://issues.apache.org/jira/browse/COMDEV-538
> Project: Community Development
>  Issue Type: Improvement
>  Components: Projects Tool
>Reporter: Konrad Windszus
>Priority: Major
>
> The PMC information is outdated in 
> https://projects.apache.org/committee.html?maven.
> The official roster shows me (kwin) correctly as being PMC member: 
> https://whimsy.apache.org/roster/committee/maven
> How often is the page in projects.a.o regenerated?



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb resolved COMDEV-436.
-
Resolution: Fixed

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb commented on COMDEV-436:
-

DOAP files are not provided for all projects, and even if present, may not be 
maintained.

Also I think the releases page is intended to include only current releases.
DOAP release entries don't have any indication of currency (and projects may 
maintain several version streams, so numeric ordering does not help)

Note that there is already a collection of all the DOAP contents in
https://projects.apache.org/json/foundation/projects.json
This includes the releases section from the original DOAP.

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb commented on COMDEV-436:
-

Please don't stop uploading items to the download area merely to fix a problem 
with the release parsing! Maybe the charts don't belong there, but that is a 
separate issue.

Whilst it is not ideal for the release listing to contain lots of spurious 
files, IMO it is better to include a few extras rather than omit valid releases.

It's easy enough to filter out additional directories if required.

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb commented on COMDEV-436:
-

The parser now runs off the find-ls listing which makes it very much quicker.

Also the matching of releases has been much simplified.
Several false positives and negatives have been addressed.

Hopefully the SOLR releases now look OK?

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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-536) Reporter Tool should filter out stats for bots

[Sebb (Jira)]

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

Sebb commented on COMDEV-536:
-

I agree it does not make sense to lump bot traffic with the rest.
However, that does not appear to be something that can be solved by changes to 
the Reporter code.

AFAICT the statistics come from Kibble, so changes will have to be addressed 
there.

> Reporter Tool should filter out stats for bots
> --
>
> Key: COMDEV-536
> URL: https://issues.apache.org/jira/browse/COMDEV-536
> Project: Community Development
>  Issue Type: Improvement
>  Components: Reporter Tool
>Reporter: Brian Demers
>Priority: Major
>
> Apache Shiro Recently migrated to GitHub. It would be useful to see the 
> project statistics excluding bot traffic, to better gauge community traffic.
> For example, this quarter 103 Pull Requests were opened in `apache/shiro`, 
> only 23 of them were from a human.
> > *NOTE:* Bot traffic IS still useful, for example if Pull Requests opened by 
> > a bot are not merged, or are sitting open for a long period of time, that 
> > may signal something to the PMC (or maybe the bot isn't useful).
> Example GitHub issues/PR filter:
> ```
> created:>2023-06-15 -author:app/dependabot 
> ```



--
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-536) Reporter Tool should filter out stats for bots

[Sebb (Jira)]

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

Sebb commented on COMDEV-536:
-

Which part of the reporter tool are you referring to? e.g. URL

> Reporter Tool should filter out stats for bots
> --
>
> Key: COMDEV-536
> URL: https://issues.apache.org/jira/browse/COMDEV-536
> Project: Community Development
>  Issue Type: Improvement
>  Components: Reporter Tool
>Reporter: Brian Demers
>Priority: Major
>
> Apache Shiro Recently migrated to GitHub. It would be useful to see the 
> project statistics excluding bot traffic, to better gauge community traffic.
> For example, this quarter 103 Pull Requests were opened in `apache/shiro`, 
> only 23 of them were from a human.
> > *NOTE:* Bot traffic IS still useful, for example if Pull Requests opened by 
> > a bot are not merged, or are sitting open for a long period of time, that 
> > may signal something to the PMC (or maybe the bot isn't useful).
> Example GitHub issues/PR filter:
> ```
> created:>2023-06-15 -author:app/dependabot 
> ```



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb commented on COMDEV-436:
-

In the meantime I have applied the patch.

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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-436) parsereleases produces false releases for solr

[Sebb (Jira)]

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

Sebb commented on COMDEV-436:
-

A release must contain a source package.

There are only a few extensions that are used for these, so I think the search 
could be considerably simplified.

> parsereleases produces false releases for solr
> --
>
> Key: COMDEV-436
> URL: https://issues.apache.org/jira/browse/COMDEV-436
> Project: Community Development
>  Issue Type: Improvement
>Reporter: Jan Høydahl
>Priority: Major
> Attachments: COMDEV-436.patch, releases.json
>
>
> When viewing [https://projects.apache.org/releases.html] and searching for 
> "solr", there are too many "falase positives".
> See the "solr" section of 
> [https://projects.apache.org/json/foundation/releases.json]
> {code:java}
>     "solr": {
>         "all.yaml": "2021-11-11",
>         "index.yaml": "2021-11-11",
>         "solr-0.5.0": "2021-11-11",
>         "solr-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-0.5.0": "2021-11-11",
>         "solr-operator-0.5.0.tgz.prov": "2021-11-11",
>         "solr-operator-v0.5.0": "2021-11-11",
>         "solrbackups.yaml": "2021-11-11",
>         "solrclouds.yaml": "2021-11-11",
>         "solrprometheusexporters.yaml": "2021-11-11",
>         "zookeeperclusters.yaml": "2021-11-11"
>     },
>  {code}
> The script mistakes some files as releases, which are really not.
> Currently the Solr downloads repo [https://downloads.apache.org/solr/] 
> contains only one release for the "solr-opereator" project, which is not a 
> traditional java code release, but rather k8s Helm-charts and CRDs. The Solr 
> main releases are currently in "lucene" so we don't expect them to show up 
> here until the 9.0 release.
> So the expected output for the current contents is simply:
> {code:java}
>     "solr": {
>         "solr-operator-0.5.0": "2021-11-11",
>     },
>  {code}



--
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: ERROR: unexpected value 'go' for plc4x in http://plc4x.apache.org/plc4x-doap.rdf

[sebb]

Sorry about that.

The intention was eventually to copy the emails to the projects, as is
done for DOAP syntax errors.
But perhaps there is a better way of doing it for these errors which
are likely to be more frequent.

Any objections to setting up a notifications list for such messages?

On Sat, 9 Sept 2023 at 04:00, Dave Fisher  wrote:
>
> Changes were made to project doap processing and now I get spammed with 
> errors once a day.
>
> Please fix this asap or I’ll have to unsubscribe to site-...@apache.org! Why 
> is a Comdev process sending errors there?
>
> Best,
> Dave
>
> Sent from my iPhone
>
> Begin forwarded message:
>
> > From: Projects 
> > Date: September 8, 2023 at 7:10:37 PM PDT
> > To: Site Development 
> > Subject: ERROR: unexpected value 'go' for plc4x in 
> > http://plc4x.apache.org/plc4x-doap.rdf
> > Reply-To: site-...@apache.org
> >
> > ERROR: unexpected value 'go' for plc4x in 
> > http://plc4x.apache.org/plc4x-doap.rdf

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

[jira] [Created] (COMDEV-535) parsereleases.py should not always strip -parent- from names

[Sebb (Jira)]

Sebb created COMDEV-535:
---

 Summary: parsereleases.py should not always strip -parent- from 
names
 Key: COMDEV-535
 URL: https://issues.apache.org/jira/browse/COMDEV-535
 Project: Community Development
  Issue Type: Bug
  Components: Reporter Tool
Reporter: Sebb


parsereleases.py currently replaces -parent- with '-' when classifying releases.

This is not always appropriate.
For example:

netbeans/netbeans/19/netbeans-19-source.zip
becomes
netbeans-19, which is fine, but
netbeans/netbeans-parent/netbeans-parent-4/netbeans-parent-4-source-release.zip
becomes
netbeans-4, which is not

Similarly for Commons and Maven.




--
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: Centralise DOAPs?

[sebb]

On Fri, 8 Sept 2023 at 14:17, Peter Hunsberger
 wrote:
>
> You could standardize on website located data with something like:
>
> project.apache.org/doap

This has long been the suggestion, as the location is unlikely to
change - unlike repo URLs.

> using the current data format, maybe with an extra layer of subproject in
> there somewhere.
>
> Even if the project frequently updates the site (including that location
> for some reason) it doesn't mean you have to invalidate any cache, just
> stick to something like a monthly crawl of the data
>
> However, getting projects to do this could be an interesting exercise!

Exactly.

This is one reason why I suggest centralising the DOAPs.

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

[jira] [Resolved] (COMDEV-302) add committe short description to committees listing

[Sebb (Jira)]

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

Sebb resolved COMDEV-302.
-
Resolution: Fixed

Fixed in r1912197

> add committe short description to committees listing
> 
>
> Key: COMDEV-302
> URL: https://issues.apache.org/jira/browse/COMDEV-302
> Project: Community Development
>  Issue Type: Wish
>  Components: Projects Tool
>Reporter: Herve Boutemy
>Priority: Major
>
> Committees by name show a list with the name only: 
> https://projects.apache.org/committees.html
> adding the short description would help people find info, and would also 
> improve the rendering (the page is quite empty with this list on the left...)



--
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: Centralise DOAPs?

[sebb]

On Fri, 8 Sept 2023 at 15:10,  wrote:
>
> On Thu, 2023-09-07 at 23:26 +0100, sebb wrote:
> > I think it would be worth considering setting up a central store for
> > DOAPs.
> > This was suggested in the past, but was rejected, I think mainly
> > because PMCs were expecting to have to make regular updates to DOAPs,
> > e.g. when releases are made, so wanted to keep them with the code.
> >
> > It's a pain keeping the releases section of DOAPs up to date (even if
> > they are local to code).
> > Now that there is an automated releases listing, I wonder whether
> > there is any point keeping the info in the DOAP as well?
> >
> > The rest of the fields in a DOAP rarely change, so it matters less if
> > the DOAP is stored in a different repo from the code to which it
> > relates.
> >
> > If DOAPs were moved to a shared GitHub repo, I think it would be much
> > easier for maintenance purposes. Some issues such as fixing an
> > incorrect repo URL or download page link could be dealt with by
> > anyone
> > with suitable karma.
> >
> > Just a thought.
>
> I'm a little torn on this one. It would certainly make it a lot easier
> for *me*, but at the expense of making it harder for the projects.

How so?

They would still be able to make changes by fixing a single file.

And the contribution process would be much easier than it is with some projects.

> We'd
> also have to go back around to every project to educate about this
> change, and address 100 different objections to the change

Provided that we did the initial setup of the central DOAPs, we'd just
have to say where the DOAPs are now located.

> What would be cool is if Git had something equivalent to svn externals,
> so that we could have the best of both worlds. Maybe some day, Git will
> catch up to where svn was 10 years ago. ;-)

I don't see how that would help.

We already have a central register.
Having Git externals would not help with maintenance, as it would
still only allow project people to update the DOAP.

> If, on the other hand, we are able to extract the frequently-changing
> stuff (ie, releases) from this data, and reduce it just to the seldom-
> changing stuff, as you suggest, this would be worth doing. It's not
> clear to me how big a lift that is, though.
>
> I would certainly like to have the ability to address some of the awful
> phrasing, grammar, and just bad project descriptions, without having to
> navigate every project's different contribution process.

And without needing to involve the project unnecessarily.

>
> -
> 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: Centralise DOAPs?

[sebb]

On Fri, 8 Sept 2023 at 11:28, Christopher  wrote:
>
> I think many projects already have their doap files on their website, do
> that's not really improving anything. It doesn't make much difference
> editing the fields embedded in HTML or in its own separate file.

It's useful to be able to submit the DOAP file to a validation
service; that's not really possible for embedded data.

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

Re: Centralise DOAPs?

[sebb]

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

Re: Drop list of languages and categories?

[sebb]

On Thu, 7 Sept 2023 at 10:17, sebb  wrote:
>
> The duplicated copies of the lists have been replaced with a single JSON file:
> https://projects.apache.org/validation.json
>
> There is also a script to process that plus the list of committees
> into create.html:
> scripts/update_create.py
>
> The intention is to use the JSON file to validate and canonicalise
> languages and categories.

Now implemented.
These entries are now canonicalised (case-adjusted) and messages are
sent to site-dev for unexpected entries.
Once the full lists are determined, the emails can be copied to the
PMCs, and the entries dropped from statistics.

> On Thu, 7 Sept 2023 at 01:25, Jarek Potiuk  wrote:
> >
> > Fully Agree.
> >
> > I looked at those when I recently learned about DOAP and I hoped they will
> > give some more information, yet all my hope was gone when I looked at them.
> >
> > J,
> >
> > On Wed, Sep 6, 2023 at 3:09 PM sebb  wrote:
> >
> > > It's a bit of a pain to maintain two copies of the lists of languages
> > > and categories.
> > >
> > > Seems to me that the pages
> > > https://projects.apache.org/categories.html
> > > https://projects.apache.org/languages.html
> > > don't provide anything that is not available from the drop-down list
> > > on the DOAP creation form.
> > >
> > > I think they should be dropped.
> > >
> > > Sebb
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> > >

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

[jira] [Commented] (COMDEV-302) add committe short description to committees listing

[Sebb (Jira)]

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

Sebb commented on COMDEV-302:
-

Note that search works quite well to find projects

> add committe short description to committees listing
> 
>
> Key: COMDEV-302
> URL: https://issues.apache.org/jira/browse/COMDEV-302
> Project: Community Development
>  Issue Type: Wish
>  Components: Projects Tool
>Reporter: Herve Boutemy
>Priority: Major
>
> Committees by name show a list with the name only: 
> https://projects.apache.org/committees.html
> adding the short description would help people find info, and would also 
> improve the rendering (the page is quite empty with this list on the left...)



--
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-528) Retired projects in DOAP list

[Sebb (Jira)]

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

Sebb resolved COMDEV-528.
-
Resolution: Fixed

These projects are now shown as being in the Attic

> Retired projects in DOAP list
> -
>
> Key: COMDEV-528
> URL: https://issues.apache.org/jira/browse/COMDEV-528
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Claude Warren
>Priority: Minor
>
> The DOAP file  list [1] as listed the DOAP for Hivemind [2] which is a 
> retired project and the specified file has an error in it.  I believe that it 
> should be commented out as other retired projects have been.
> [1] 
> [https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml]
> [2] 
> [http://svn.apache.org/repos/asf/hivemind/hivemind2/trunk/doap_Hivemind.rdf]
>  



--
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-328) Don't publish second-hand json files

[Sebb (Jira)]

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

Sebb resolved COMDEV-328.
-
Resolution: Fixed

> Don't publish second-hand json files
> 
>
> Key: COMDEV-328
> URL: https://issues.apache.org/jira/browse/COMDEV-328
> Project: Community Development
>  Issue Type: Improvement
>  Components: PhoneBook
>Reporter: Sebb
>Priority: Major
>
> Originally, home.a.o extracted its own data files which it published in
> https://home.apache.org/public/
> However, the files there are now just copies of the ones created by Whimsy.
> It would be better to direct users to the originals.
> e.g. with a redirect?



--
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: projects.a.o "maintainer" field

[sebb]

On Thu, 7 Sept 2023 at 18:19, Craig Russell  wrote:
>
> I think projects would just put  as the name and dev@project... as 
> the mail address. But there is already a mail-list field so it seems 
> redundant.
>
> So I agree that we should drop "maintainer".

Agreed; it can be dropped from the create form.

If there is to be a default, it should be private@
Not all projects have a dev list; ultimately it is the PMC that is
responsible for the DOAP.

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

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

Centralise DOAPs?

[sebb]

I think it would be worth considering setting up a central store for DOAPs.
This was suggested in the past, but was rejected, I think mainly
because PMCs were expecting to have to make regular updates to DOAPs,
e.g. when releases are made, so wanted to keep them with the code.

It's a pain keeping the releases section of DOAPs up to date (even if
they are local to code).
Now that there is an automated releases listing, I wonder whether
there is any point keeping the info in the DOAP as well?

The rest of the fields in a DOAP rarely change, so it matters less if
the DOAP is stored in a different repo from the code to which it
relates.

If DOAPs were moved to a shared GitHub repo, I think it would be much
easier for maintenance purposes. Some issues such as fixing an
incorrect repo URL or download page link could be dealt with by anyone
with suitable karma.

Just a thought.

Sebb

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

Not all DOAP fields are useful!

[sebb]

The DOAP create page includes several fields that I think have limited
(if any use).

This makes it harder for projects to use the page, so unless a field
is genuinely useful, I think it should be dropped.

There are several fields which are not available elsewhere, and should
be considered essential:
 Project name & PMC [needed for uniqueness and identification]
Short and long description
Categories
Programming Languages

These are all likely to be quite stable (languages might change), so
should only need to be set up once.

These should be readily available from the project website:
Bug database
Download page
Mailing lists page
SVN repository
Git repository

Experience shows that these are rarely maintained, so should probably
be dropped.
But if it is decided to keep them, there needs to be some way to check
that they are still correct.

The releases section is also a pain to maintain (and the syntax is awkward).
I'm not sure it is even needed, now that there is the Project Release Listing:
https://projects.apache.org/releases.html

Maintainer is completely unnecessary.

It might be useful to retain the Implemented standard, though it is
very rarely used.

I think simplifying the form would make it less of a chore for PMCs.

Sebb

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

Re: Valid languages for projects.apache.org

[sebb]

On Thu, 7 Sept 2023 at 13:36, Andrew Wetmore  wrote:
>
> Apache Royale uses significant numbers of MXML files in applications. Is
> that sufficiently different from XML that we should add it?

AFAICT MXML is a domain-specific superset of XML.
I don't think that deserves a separate language category.

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

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

Valid categories for projects.apache.org

[sebb]

As for languages, some DOAPs currently contain categories that don't
agree with the current valid list.

The outliers are:

data-management-platform
distributed-sql-database
education
ftp
geospatial
graphics
hadoop
IDE
identity-management
identity-provisioning
integration
Kerberos
observability
SDK
search
templating
virtual-machine

I think some of the above could be added, possibly under a more general heading.
For example, graphics could make a reasonable category.
However, distributed-sql-database and Kerberos seem too specific.
ftp is probably part of network-client/network-server

Plus the following, which are all languages.
I think they can safely be disallowed as categories:
C
C++
Go
Groovy
HTML
Java
PHP
Python
Regexp
SQL

Thoughts?

Sebb

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

Valid languages for projects.apache.org

[sebb]

There are currently a few project DOAPs which use languages not in the
current valid list.

These are:

BASH/Bash
Freemarker
Haxe
JDBC
ODBC
SQL
XML

Whilst we could add Bash, we might then need to add all the other
Shell languages.
Freemarker is a templating language; could be added
Haxe is a valid language; could perhaps be added
JDBC and ODBC are not languages; I think they should be dropped from
the classification.
SQL and XML can perhaps be considered languages

WDYT?

Sebb

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

Re: Drop list of languages and categories?

[sebb]

The duplicated copies of the lists have been replaced with a single JSON file:
https://projects.apache.org/validation.json

There is also a script to process that plus the list of committees
into create.html:
scripts/update_create.py

The intention is to use the JSON file to validate and canonicalise
languages and categories.

On Thu, 7 Sept 2023 at 01:25, Jarek Potiuk  wrote:
>
> Fully Agree.
>
> I looked at those when I recently learned about DOAP and I hoped they will
> give some more information, yet all my hope was gone when I looked at them.
>
> J,
>
> On Wed, Sep 6, 2023 at 3:09 PM sebb  wrote:
>
> > It's a bit of a pain to maintain two copies of the lists of languages
> > and categories.
> >
> > Seems to me that the pages
> > https://projects.apache.org/categories.html
> > https://projects.apache.org/languages.html
> > don't provide anything that is not available from the drop-down list
> > on the DOAP creation form.
> >
> > I think they should be dropped.
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >

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

Re: RFC: many PMCs have not provided DOAPs

[sebb]

On Wed, 6 Sept 2023 at 13:51, Michael Sokolov  wrote:
>
> Perhaps if we used the information in these files to drive creation of
> the board report templates in whimsy, projects would have some
> stronger incentive to keep them up to date? Or ... maybe we do that
> already? I'm not sure though because for example we provide
>
> 
>   
>  rdf:resource="https://git-wip-us.apache.org/repos/asf/lucene.git"/>
>   
> 
>
> Yet whimsy's reports on number of commits for the Lucene project
> doesn't seem to be observing that repo, but rather some other ones.

Whimsy does not report on commit counts.
Perhaps you mean reporter?

> On Tue, Sep 5, 2023 at 12:21 PM sebb  wrote:
> >
> > On Tue, 5 Sept 2023 at 16:28,  wrote:
> > >
> > > On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote:
> > > > I think a lot of DOAP files may be out of date as well. At least for
> > > > Wicket
> > > > we have moved our site SCM from svn to git a long time ago, but
> > > > didn't
> > > > realise that project.a.o needed updating.
> > > >
> > > > Suffice to say, Wicket has had several (major and minor) releases
> > > > since
> > > > 2015-02-02...
> > >
> > > Hmm. Isn't that information available somewhere else, without having to
> > > manually update a file?
> > >
> > > But, yeah, this is a great point. Thanks for mentioning it.
> >
> > The DOAP syntax allows for a lot of data that is better stored elsewhere.
> >
> > The bits that are unique to the DOAP are less likely to change, for example:
> > - pmc
> > - short and long description
> > - language(s)
> > - category(ies)
> > - homepage
> > - standard(s) if any
> >
> > I think these are the most important from the point of view of showing
> > the range of projects at the ASF and enabling people to find a project
> > that suits their interests and skills.
> >
> > I doubt it will ever be possible to ensure that fields like releases
> > are kept up to date.
> > It should be possible to get an idea of releases from the distribution
> > repo (though the file naming can make that a bit of a challenge!)
> >
> > Likewise the SVM and download URLs should be readily available from
> > the homepage.
> >
> >
> > > --Rich
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Drop list of languages and categories?

[sebb]

It's a bit of a pain to maintain two copies of the lists of languages
and categories.

Seems to me that the pages
https://projects.apache.org/categories.html
https://projects.apache.org/languages.html
don't provide anything that is not available from the drop-down list
on the DOAP creation form.

I think they should be dropped.

Sebb

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

Incorrect categories in DOAPs

[sebb]

I've just noticed that there are some DOAPs using rather odd categories.

For example 'C', 'PHP', 'Groovy', 'SQL'.

Seems to me that these are languages, not categories.

I think these should be disallowed as categories; they just clutter
the category listings and distort the statistics.

WDYT?

Sebb

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

Re: RFC: many PMCs have not provided DOAPs

[sebb]

On Wed, 6 Sept 2023 at 09:13, Jarek Potiuk  wrote:
>
> We just added DOAP for airflow (core project) and I am planning to add
> release information for it automatically as well now when I see it working.
>
> I have a question about good practices though, before I make the next step
> - which is automating generation of all the DOAPs of ours.
>
> In the Apache Airflow PMC we are regularly releasing ~ 90 packages. Almost
> all of them come from the same monorepo and are technically separate
> artifacts / releases and they have their own releases (each of the packages
> follows SemVer versioning and they versioning is independent in each
> package).
>
> I believe the idea of DOAP is that if a PMC releases more than one project,
> each of them should have its own DOAP?

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

However if they are effectively part of the same product then it is less clear.

So for example Commons components can all be used independently and
have individual DOAPs
Likewise HttpComponents.
I'm not sure why HTTPServer singles out mod_ftp; I'm not sure it would
be useful to include all the add-on HTTP modules.

> So I am thinking about adding (automatically) DOAPs for all the ~90
> packages (we have airflow core + airflow providers). Is that a good idea ?

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

The purpose of the site is to provide information about ASF projects.
Would it help the general public to have all these extra details?

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

> I believe it will inflate and impact the total numbers (out of the sudden,
> Python will become the strong second in the pie-chart here
> https://projects.apache.org/ and we will have almost 90 "Apache Airflow
> Provider " projects in the various lists produced by `
> projects.apache.org" - pretty much dominating some categories (you can see
> all the provider packages we release here:
> https://airflow.apache.org/docs/#providers-packagesdocsapache-airflow-providersindexhtml
> )
>
> Is that something that we consider as "good practice"  and expected to
> happen in this case? Will that cause problems for anyone ?

No and yes
;-}


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

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

Re: (NuttX) Re: Missing DOAP file

[sebb]

On Tue, 5 Sept 2023 at 18:38, Rich Bowen  wrote:
>
> On Tue, 2023-09-05 at 14:29 -0300, Alan C. Assis wrote:
> > Hi Rich,
> >
> > Thank you very much for let us to know about it.
> >
> > Before you create the DOAP, could you please include the Category:
> > RTOS or IoT ?
> >
> > NuttX doesn't fit in any of existing categories: Big Data, Build
> > Management, Cloud, etc.
>
>
> Hey, folks, NuttX has requested the addition of a new category or
> categories for projects.apache.org. Are there any objections to me
> creating this?

I don't see why not.

AFAIK, there aren't any formal rules for what categories are allowed,
but it would be good to keep the categories as general as possible.
If the categories are too specific, there is a danger that closely
related projects end up in different categories.

Note that a project can be added to multiple categories.

> This seemed a larger, less reversible step than updating data, so I
> wanted to be sure to get some broader feedback.
>
> Thanks.
>
> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: RFC: many PMCs have not provided DOAPs

[sebb]

On Tue, 5 Sept 2023 at 16:28,  wrote:
>
> On Tue, 2023-09-05 at 17:11 +0200, Martijn Dashorst wrote:
> > I think a lot of DOAP files may be out of date as well. At least for
> > Wicket
> > we have moved our site SCM from svn to git a long time ago, but
> > didn't
> > realise that project.a.o needed updating.
> >
> > Suffice to say, Wicket has had several (major and minor) releases
> > since
> > 2015-02-02...
>
> Hmm. Isn't that information available somewhere else, without having to
> manually update a file?
>
> But, yeah, this is a great point. Thanks for mentioning it.

The DOAP syntax allows for a lot of data that is better stored elsewhere.

The bits that are unique to the DOAP are less likely to change, for example:
- pmc
- short and long description
- language(s)
- category(ies)
- homepage
- standard(s) if any

I think these are the most important from the point of view of showing
the range of projects at the ASF and enabling people to find a project
that suits their interests and skills.

I doubt it will ever be possible to ensure that fields like releases
are kept up to date.
It should be possible to get an idea of releases from the distribution
repo (though the file naming can make that a bit of a challenge!)

Likewise the SVM and download URLs should be readily available from
the homepage.


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

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

[jira] [Commented] (COMDEV-534) 3rd party downloads not allowed by privacy policy

[Sebb (Jira)]

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

Sebb commented on COMDEV-534:
-

The statistics page loads data from api.snoot.io.

AFAICT, we don't have a privacy agreement with them, and their website privacy 
policy [1] says they may collect PII, and furthermore that the Policy can be 
changed at any time without notice. Furthermore, the link to the vendor's 
website is broken.


[1] https://snoot.io/privacy.html

> 3rd party downloads not allowed by privacy policy
> -
>
> Key: COMDEV-534
> URL: https://issues.apache.org/jira/browse/COMDEV-534
> Project: Community Development
>  Issue Type: Bug
>  Components: Projects Tool
>Reporter: Sebb
>Priority: Major
>
> The projects.a.o website relies on Google charts.
> AFAIK, we don't have a privacy agreement for these, and according to the 
> terms of use, they cannot be used downloaded and used locally:
> https://developers.google.com/chart/interactive/faq#offline
> Some possible solutions:
> - use an alternative charting library that is not in conflict with the 
> Privacy Policy
> - ask the user's permission before making requests to such 3rd party sites; 
> if the user refuses, charts and graphs cannot be displayed, but the site 
> should otherwise continue to function
> - find some way of proxying the requests via an ASF host that strips out all 
> client-specific headers.



--
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] [Created] (COMDEV-534) 3rd party downloads not allowed by privacy policy

[Sebb (Jira)]

Sebb created COMDEV-534:
---

 Summary: 3rd party downloads not allowed by privacy policy
 Key: COMDEV-534
 URL: https://issues.apache.org/jira/browse/COMDEV-534
 Project: Community Development
  Issue Type: Bug
  Components: Projects Tool
Reporter: Sebb


The projects.a.o website relies on Google charts.

AFAIK, we don't have a privacy agreement for these, and according to the terms 
of use, they cannot be used downloaded and used locally:
https://developers.google.com/chart/interactive/faq#offline

Some possible solutions:
- use an alternative charting library that is not in conflict with the Privacy 
Policy
- ask the user's permission before making requests to such 3rd party sites; if 
the user refuses, charts and graphs cannot be displayed, but the site should 
otherwise continue to function
- find some way of proxying the requests via an ASF host that strips out all 
client-specific headers.



--
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-533) Inconsistency in membership data (CouchDB)

[Sebb (Jira)]

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

Sebb commented on COMDEV-533:
-

The official date of joining is when the person is added to the roster.
Sorry, but that cannot be changed, it is a fact of history.

> Inconsistency in membership data (CouchDB)
> --
>
> Key: COMDEV-533
> URL: https://issues.apache.org/jira/browse/COMDEV-533
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
>Reporter: Páli Gábor
>Priority: Major
>
> When the quarterly report body is generated via 
> [https://reporter.apache.org/wizard/?couchdb] for the CouchDB project, the 
> "Membership Data" section contains information that is not exactly correct.
> The latest PMC member was not Glynn Bird but Ronny Berndt and it was 
> announced on 2023-03-04 on the dev@ mailing list: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2023-3] .  Glynn Bird 
> has joined the PMC on 2020-09-14: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2020-9] .



--
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-533) Inconsistency in membership data (CouchDB)

[Sebb (Jira)]

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

Sebb commented on COMDEV-533:
-

Only PMC members are allowed to modify the file.
This is normally done via the Whimsy PMC roster page, as that ensures the 
correct syntax is used and adjusts any related LDAP groups.

A summary of the contents of the CI file can also be found here:
https://whimsy.apache.org/public/committee-info.json

Although Glynn Bird was voted to be invited to join the PMC in Sep 2020, it 
looks as though the PMC forgot to update the roster until March 2023.

> Inconsistency in membership data (CouchDB)
> --
>
> Key: COMDEV-533
> URL: https://issues.apache.org/jira/browse/COMDEV-533
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
>Reporter: Páli Gábor
>Priority: Major
>
> When the quarterly report body is generated via 
> [https://reporter.apache.org/wizard/?couchdb] for the CouchDB project, the 
> "Membership Data" section contains information that is not exactly correct.
> The latest PMC member was not Glynn Bird but Ronny Berndt and it was 
> announced on 2023-03-04 on the dev@ mailing list: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2023-3] .  Glynn Bird 
> has joined the PMC on 2020-09-14: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2020-9] .



--
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-533) Inconsistency in membership data (CouchDB)

[Sebb (Jira)]

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

Sebb resolved COMDEV-533.
-
Resolution: Information Provided

> Inconsistency in membership data (CouchDB)
> --
>
> Key: COMDEV-533
> URL: https://issues.apache.org/jira/browse/COMDEV-533
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
>Reporter: Páli Gábor
>Priority: Major
>
> When the quarterly report body is generated via 
> [https://reporter.apache.org/wizard/?couchdb] for the CouchDB project, the 
> "Membership Data" section contains information that is not exactly correct.
> The latest PMC member was not Glynn Bird but Ronny Berndt and it was 
> announced on 2023-03-04 on the dev@ mailing list: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2023-3] .  Glynn Bird 
> has joined the PMC on 2020-09-14: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2020-9] .



--
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-533) Inconsistency in membership data (CouchDB)

[Sebb (Jira)]

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

Sebb commented on COMDEV-533:
-

The official membership roster is the committee-info.txt file.

Unless and until a person is added to the file, they are not officially a 
member of the PMC.

The dates from committee-inf.txt can be seen in the Whimsy page for CouchDB:

[https://whimsy.apache.org/roster/committee/couchdb]

This shows:
Glynn Bird 2023-03-14
Ronny Berndt 2023-03-03

 

 

> Inconsistency in membership data (CouchDB)
> --
>
> Key: COMDEV-533
> URL: https://issues.apache.org/jira/browse/COMDEV-533
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
>Reporter: Páli Gábor
>Priority: Major
>
> When the quarterly report body is generated via 
> [https://reporter.apache.org/wizard/?couchdb] for the CouchDB project, the 
> "Membership Data" section contains information that is not exactly correct.
> The latest PMC member was not Glynn Bird but Ronny Berndt and it was 
> announced on 2023-03-04 on the dev@ mailing list: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2023-3] .  Glynn Bird 
> has joined the PMC on 2020-09-14: 
> [https://lists.apache.org/list?d...@couchdb.apache.org:2020-9] .



--
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-532) Report Wizard gives "[object Response]" error with underlying 500

[Sebb (Jira)]

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

Sebb resolved COMDEV-532.
-
Resolution: Fixed

Works again.

> Report Wizard gives "[object Response]" error with underlying 500
> -
>
> Key: COMDEV-532
> URL: https://issues.apache.org/jira/browse/COMDEV-532
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
> Environment: macOS Ventura 13.4.1 (c), Firefox 116.0.3 (64-bit)
>Reporter: Páli Gábor
>Priority: Major
>
> As reported by others, navigating to 
> [https://reporter.apache.org/wizard/?couchdb|https://reporter.apache.org/wizard/?couchdb]
>  pops up a blank notification error, and does nothing else.
> Console shows an underlying 500:
> /*** ASF Board Report Wizard initializing / 
> [wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Initializing escrow checks 
> [wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Fetching JSON resource at /api/overview?couchdb 
> [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> putting /api/overview?couchdb in escrow... 
> [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> URL /api/overview?couchdb returned HTTP code 500, snapping!  
> [wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> It might be related that I am not on the CouchDB PMC, but I believe it should 
> still respond sensibly.



--
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] [Updated] (COMDEV-532) Report Wizard gives "[object Response]" error with underlying 500

[Sebb (Jira)]

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

Sebb updated COMDEV-532:

Description: 
As reported by others, navigating to 
[https://reporter.apache.org/wizard/?couchdb|https://reporter.apache.org/wizard/?couchdb]
 pops up a blank notification error, and does nothing else.

Console shows an underlying 500:
/*** ASF Board Report Wizard initializing / 
[wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
Initializing escrow checks 
[wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
Fetching JSON resource at /api/overview?couchdb 
[wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
putting /api/overview?couchdb in escrow... 
[wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
URL /api/overview?couchdb returned HTTP code 500, snapping!  
[wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]

It might be related that I am not on the CouchDB PMC, but I believe it should 
still respond sensibly.

  was:
As reported by others, navigating to 
[https://reporter.apache.org/wizard/?couchdb|https://reporter.apache.org/wizard/]
 pops up a blank notification error, and does nothing else.

Console shows an underlying 500:
/*** ASF Board Report Wizard initializing / 
[wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
Initializing escrow checks 
[wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
Fetching JSON resource at /api/overview?couchdb 
[wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
putting /api/overview?couchdb in escrow... 
[wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
URL /api/overview?couchdb returned HTTP code 500, snapping!  
[wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]

It might be related that I am not on the CouchDB PMC, but I believe it should 
still respond sensibly.


> Report Wizard gives "[object Response]" error with underlying 500
> -
>
> Key: COMDEV-532
> URL: https://issues.apache.org/jira/browse/COMDEV-532
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
> Environment: macOS Ventura 13.4.1 (c), Firefox 116.0.3 (64-bit)
>Reporter: Páli Gábor
>Priority: Major
>
> As reported by others, navigating to 
> [https://reporter.apache.org/wizard/?couchdb|https://reporter.apache.org/wizard/?couchdb]
>  pops up a blank notification error, and does nothing else.
> Console shows an underlying 500:
> /*** ASF Board Report Wizard initializing / 
> [wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Initializing escrow checks 
> [wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Fetching JSON resource at /api/overview?couchdb 
> [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> putting /api/overview?couchdb in escrow... 
> [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> URL /api/overview?couchdb returned HTTP code 500, snapping!  
> [wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> It might be related that I am not on the CouchDB PMC, but I believe it should 
> still respond sensibly.



--
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-532) Report Wizard gives "[object Response]" error with underlying 500

[Sebb (Jira)]

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

Sebb commented on COMDEV-532:
-

Sorry, I'd not noticed that clicking on the link in the description did not 
include the query part of the URL.

However, I have just tried the full URL:
https://reporter.apache.org/wizard/?couchdb 
and that works fine for me even even with a relatively unprivileged login.

> Report Wizard gives "[object Response]" error with underlying 500
> -
>
> Key: COMDEV-532
> URL: https://issues.apache.org/jira/browse/COMDEV-532
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
> Environment: macOS Ventura 13.4.1 (c), Firefox 116.0.3 (64-bit)
>Reporter: Páli Gábor
>Priority: Major
>
> As reported by others, navigating to 
> [https://reporter.apache.org/wizard/?couchdb|https://reporter.apache.org/wizard/]
>  pops up a blank notification error, and does nothing else.
> Console shows an underlying 500:
> /*** ASF Board Report Wizard initializing / 
> [wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Initializing escrow checks 
> [wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Fetching JSON resource at /api/overview?couchdb 
> [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> putting /api/overview?couchdb in escrow... 
> [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> URL /api/overview?couchdb returned HTTP code 500, snapping!  
> [wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> It might be related that I am not on the CouchDB PMC, but I believe it should 
> still respond sensibly.



--
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-532) Report Wizard gives "[object Response]" error with underlying 500

[Sebb (Jira)]

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

Sebb commented on COMDEV-532:
-

Tried just now, and the wizard loads OK for me with macOS and FF, Chrome and 
Safari.

> Report Wizard gives "[object Response]" error with underlying 500
> -
>
> Key: COMDEV-532
> URL: https://issues.apache.org/jira/browse/COMDEV-532
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
> Environment: macOS Ventura 13.4.1 (c), Firefox 116.0.3 (64-bit)
>Reporter: Páli Gábor
>Priority: Major
>
> As reported by others, navigating to [https://reporter.apache.org/wizard/] 
> pops up a blank notification error, and does nothing else.
> Console shows an underlying 500:
> /*** ASF Board Report Wizard initializing / 
> [wizard.js:1799:9|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Initializing escrow checks 
> [wizard.js:1825:17|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> Fetching JSON resource at /api/overview?couchdb 
> [wizard.js:79:13|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> putting /api/overview?couchdb in escrow... 
> [wizard.js:96:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
> URL /api/overview?couchdb returned HTTP code 500, snapping!  
> [wizard.js:132:21|https://reporter.apache.org/wizard/js/wizard.js?unified-1.4]
>  



--
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: [ASF M & Conferences] Community Over Code logo for project sites

[sebb]

On Wed, 16 Aug 2023 at 11:00, Daniel Gruno  wrote:
>
> On 2023-08-16 11:47, sebb wrote:
> > On Wed, 16 Aug 2023 at 10:19, Daniel Gruno  wrote:
> >>
> >> On 2023-08-16 10:46, Roy Lenferink wrote:
> >>> Op wo 16 aug 2023 om 07:19 schreef Daniel Gruno :
> >>>
> >>>> On 2023-08-15 22:37, sebb wrote:
> >>>>> On Tue, 15 Aug 2023 at 18:55, Brian Proffitt  wrote:
> >>>>>>
> >>>>>> All:
> >>>>>>
> >>>>>> ASF’s flagship event, Community Over Code, is happening October 7-10
> >>>>>> in Halifax, Nova Scotia (formerly called ApacheCon).
> >>>>>>
> >>>>>> I would like to ask all projects to add the logo and event URL to your
> >>>>>> project website to help the ASF promote the event - and thank you to
> >>>>>> projects who have already done this! Or, if you'd like, promote the
> >>>>>> event with the logos on your project's social media channels.
> >>>>>>
> >>>>>> Logos:
> >>>>>> https://apache.org/foundation/press/kit/#eventlogo
> >>>>>>
> >>>>>> Event URL:
> >>>>>> https://communityovercode.org/
> >>>>>>
> >>>>>> Thank you!
> >>>>>> BKP
> >>>>>
> >>>>> There is already a standard way to do this, as is done by:
> >>>>>
> >>>>> https://jmeter.apache.org/
> >>>>> https://commons.apache.org/
> >>>>> https://hc.apache.org/
> >>>>>
> >>>>> and probably others that use Maven to build their sites.
> >>>>>
> >>>>> They include a link to the event page:
> >>>>> https://www.apache.org/events/current-event.html
> >>>>> with an image such as
> >>>>> https://www.apache.org/events/current-event-125x125.png
> >>>>
> >>>> There is even a newer way, https://www.apachecon.com/event-images/ which
> >>>> most project sites use by now, and which already features the community
> >>>> over code logo as the current event.
> >>>>
> >>>
> >>> Whimsy has a check for ^https?://.*apache.org/events/current-event which
> >>> checks
> >>> against the 'current-event' image/link:
> >>> https://whimsy.apache.org/site/check/events
> >>>
> >>> (also part of the site-scan overview: https://whimsy.apache.org/site/ )
> >>>
> >>> It seems that 104 projects link to the 'current-event' image/link.
> >>>
> >>> I remember that the current-event image previously was also used for the
> >>> Apache Roadshows, so not only ApacheCon.
> >>
> >> I think this is more of a naming issue than anything, and I believe the
> >> conferences team is aware that they need to work towards a
> >> wider-encompassing name here.
> >>
> >>>
> >>> Having a look at the project list (I used the Whimsy list): of the first 
> >>> 10
> >>> projects
> >>> 6 use the current-event image/link, 1 also has the Community over code
> >>> image (Accumulo)
> >>> and 1 contains a direct link to apachecon.com without an image (AGE).
> >>>
> >>> Checking the community.a.o website, even there the current-event 
> >>> image/link
> >>> is used.
> >>>
> >>> So to me it seems that not a lot of websites use 
> >>> apachecon.com/event-images/
> >>> and it
> >>> would be simpler to update the current-event images.
> >>
> >> In the short term, I would agree. In the longer term, I would hope that
> >> the recommendations from the conferences team (which is to use the
> >> event-images snippet) would be followed. The current-event image is
> >> quite limited in that it's a single image of a fixed size, so it may not
> >> work for a specific web site theme, and it will only ever be usable for
> >> a single event at a time. The event-images snippet was made to address
> >> these issues by supporting both dark and light themes as well as
> >> multiple events occurring at the same time.
> >
> > Sites which use the admittedly limited images provided by the
> > old-style 'current-event' solution will have allowed for this.
> > Though of course, more sizes co

Re: [ASF M & Conferences] Community Over Code logo for project sites

[sebb]

On Wed, 16 Aug 2023 at 14:25, Brian Proffitt  wrote:
>
> Okay, thanks for the update on the two processes. I was not aware of
> them, obviously. I will get the images into that site.

Great, that will save a lot of effort for projects that use this method.

>
> Brian Proffitt
> VP, Marketing & Publicity
>
> On Wed, Aug 16, 2023 at 6:00 AM Daniel Gruno  wrote:
> >
> > On 2023-08-16 11:47, sebb wrote:
> > > On Wed, 16 Aug 2023 at 10:19, Daniel Gruno  wrote:
> > >>
> > >> On 2023-08-16 10:46, Roy Lenferink wrote:
> > >>> Op wo 16 aug 2023 om 07:19 schreef Daniel Gruno :
> > >>>
> > >>>> On 2023-08-15 22:37, sebb wrote:
> > >>>>> On Tue, 15 Aug 2023 at 18:55, Brian Proffitt  wrote:
> > >>>>>>
> > >>>>>> All:
> > >>>>>>
> > >>>>>> ASF’s flagship event, Community Over Code, is happening October 7-10
> > >>>>>> in Halifax, Nova Scotia (formerly called ApacheCon).
> > >>>>>>
> > >>>>>> I would like to ask all projects to add the logo and event URL to 
> > >>>>>> your
> > >>>>>> project website to help the ASF promote the event - and thank you to
> > >>>>>> projects who have already done this! Or, if you'd like, promote the
> > >>>>>> event with the logos on your project's social media channels.
> > >>>>>>
> > >>>>>> Logos:
> > >>>>>> https://apache.org/foundation/press/kit/#eventlogo
> > >>>>>>
> > >>>>>> Event URL:
> > >>>>>> https://communityovercode.org/
> > >>>>>>
> > >>>>>> Thank you!
> > >>>>>> BKP
> > >>>>>
> > >>>>> There is already a standard way to do this, as is done by:
> > >>>>>
> > >>>>> https://jmeter.apache.org/
> > >>>>> https://commons.apache.org/
> > >>>>> https://hc.apache.org/
> > >>>>>
> > >>>>> and probably others that use Maven to build their sites.
> > >>>>>
> > >>>>> They include a link to the event page:
> > >>>>> https://www.apache.org/events/current-event.html
> > >>>>> with an image such as
> > >>>>> https://www.apache.org/events/current-event-125x125.png
> > >>>>
> > >>>> There is even a newer way, https://www.apachecon.com/event-images/ 
> > >>>> which
> > >>>> most project sites use by now, and which already features the community
> > >>>> over code logo as the current event.
> > >>>>
> > >>>
> > >>> Whimsy has a check for ^https?://.*apache.org/events/current-event which
> > >>> checks
> > >>> against the 'current-event' image/link:
> > >>> https://whimsy.apache.org/site/check/events
> > >>>
> > >>> (also part of the site-scan overview: https://whimsy.apache.org/site/ )
> > >>>
> > >>> It seems that 104 projects link to the 'current-event' image/link.
> > >>>
> > >>> I remember that the current-event image previously was also used for the
> > >>> Apache Roadshows, so not only ApacheCon.
> > >>
> > >> I think this is more of a naming issue than anything, and I believe the
> > >> conferences team is aware that they need to work towards a
> > >> wider-encompassing name here.
> > >>
> > >>>
> > >>> Having a look at the project list (I used the Whimsy list): of the 
> > >>> first 10
> > >>> projects
> > >>> 6 use the current-event image/link, 1 also has the Community over code
> > >>> image (Accumulo)
> > >>> and 1 contains a direct link to apachecon.com without an image (AGE).
> > >>>
> > >>> Checking the community.a.o website, even there the current-event 
> > >>> image/link
> > >>> is used.
> > >>>
> > >>> So to me it seems that not a lot of websites use 
> > >>> apachecon.com/event-images/
> > >>> and it
> > >>> would be simpler to update the current-event images.
> > >>
> > >> In the short term,

Re: [ASF M & Conferences] Community Over Code logo for project sites

[sebb]

On Wed, 16 Aug 2023 at 10:19, Daniel Gruno  wrote:
>
> On 2023-08-16 10:46, Roy Lenferink wrote:
> > Op wo 16 aug 2023 om 07:19 schreef Daniel Gruno :
> >
> >> On 2023-08-15 22:37, sebb wrote:
> >>> On Tue, 15 Aug 2023 at 18:55, Brian Proffitt  wrote:
> >>>>
> >>>> All:
> >>>>
> >>>> ASF’s flagship event, Community Over Code, is happening October 7-10
> >>>> in Halifax, Nova Scotia (formerly called ApacheCon).
> >>>>
> >>>> I would like to ask all projects to add the logo and event URL to your
> >>>> project website to help the ASF promote the event - and thank you to
> >>>> projects who have already done this! Or, if you'd like, promote the
> >>>> event with the logos on your project's social media channels.
> >>>>
> >>>> Logos:
> >>>> https://apache.org/foundation/press/kit/#eventlogo
> >>>>
> >>>> Event URL:
> >>>> https://communityovercode.org/
> >>>>
> >>>> Thank you!
> >>>> BKP
> >>>
> >>> There is already a standard way to do this, as is done by:
> >>>
> >>> https://jmeter.apache.org/
> >>> https://commons.apache.org/
> >>> https://hc.apache.org/
> >>>
> >>> and probably others that use Maven to build their sites.
> >>>
> >>> They include a link to the event page:
> >>> https://www.apache.org/events/current-event.html
> >>> with an image such as
> >>> https://www.apache.org/events/current-event-125x125.png
> >>
> >> There is even a newer way, https://www.apachecon.com/event-images/ which
> >> most project sites use by now, and which already features the community
> >> over code logo as the current event.
> >>
> >
> > Whimsy has a check for ^https?://.*apache.org/events/current-event which
> > checks
> > against the 'current-event' image/link:
> > https://whimsy.apache.org/site/check/events
> >
> > (also part of the site-scan overview: https://whimsy.apache.org/site/ )
> >
> > It seems that 104 projects link to the 'current-event' image/link.
> >
> > I remember that the current-event image previously was also used for the
> > Apache Roadshows, so not only ApacheCon.
>
> I think this is more of a naming issue than anything, and I believe the
> conferences team is aware that they need to work towards a
> wider-encompassing name here.
>
> >
> > Having a look at the project list (I used the Whimsy list): of the first 10
> > projects
> > 6 use the current-event image/link, 1 also has the Community over code
> > image (Accumulo)
> > and 1 contains a direct link to apachecon.com without an image (AGE).
> >
> > Checking the community.a.o website, even there the current-event image/link
> > is used.
> >
> > So to me it seems that not a lot of websites use apachecon.com/event-images/
> > and it
> > would be simpler to update the current-event images.
>
> In the short term, I would agree. In the longer term, I would hope that
> the recommendations from the conferences team (which is to use the
> event-images snippet) would be followed. The current-event image is
> quite limited in that it's a single image of a fixed size, so it may not
> work for a specific web site theme, and it will only ever be usable for
> a single event at a time. The event-images snippet was made to address
> these issues by supporting both dark and light themes as well as
> multiple events occurring at the same time.

Sites which use the admittedly limited images provided by the
old-style 'current-event' solution will have allowed for this.
Though of course, more sizes could be provided. Also the HTML could
include links to multiple events.
So I don't see those as critical issues.

Projects should not be forced to change unnecessarily.

Of course if they wish to use the replacement solution they can do so.
And can be encouraged to do so as part of any site redesign.

Note that the new solution uses Javascript.
There is no fallback for browsers that don't support Javascript.
This may be a problem for some assistive readers.

Sebb
> >
> >
> >>>
> >>> The idea behind this was to avoid having to change loads of websites
> >>> before and after every event.
> >>> Instead, the event organisers can change the page content (or add a
> >>> redirect) and the various sized images accordingly.
> >>>
> >>> By the way, the S

Re: [ASF M & Conferences] Community Over Code logo for project sites

[sebb]

On Wed, 16 Aug 2023 at 06:19, Daniel Gruno  wrote:
>
> On 2023-08-15 22:37, sebb wrote:
> > On Tue, 15 Aug 2023 at 18:55, Brian Proffitt  wrote:
> >>
> >> All:
> >>
> >> ASF’s flagship event, Community Over Code, is happening October 7-10
> >> in Halifax, Nova Scotia (formerly called ApacheCon).
> >>
> >> I would like to ask all projects to add the logo and event URL to your
> >> project website to help the ASF promote the event - and thank you to
> >> projects who have already done this! Or, if you'd like, promote the
> >> event with the logos on your project's social media channels.
> >>
> >> Logos:
> >> https://apache.org/foundation/press/kit/#eventlogo
> >>
> >> Event URL:
> >> https://communityovercode.org/
> >>
> >> Thank you!
> >> BKP
> >
> > There is already a standard way to do this, as is done by:
> >
> > https://jmeter.apache.org/
> > https://commons.apache.org/
> > https://hc.apache.org/
> >
> > and probably others that use Maven to build their sites.
> >
> > They include a link to the event page:
> > https://www.apache.org/events/current-event.html
> > with an image such as
> > https://www.apache.org/events/current-event-125x125.png
>
> There is even a newer way, https://www.apachecon.com/event-images/ which
> most project sites use by now, and which already features the community
> over code logo as the current event.

I did not know about that.

But that should not mean the previous method has to be abandoned.


> >
> > The idea behind this was to avoid having to change loads of websites
> > before and after every event.
> > Instead, the event organisers can change the page content (or add a
> > redirect) and the various sized images accordingly.
> >
> > By the way, the SVG and PNG versions of the logo look very different -
> > is that intentional?
> >
> >> Brian Proffitt
> >> VP, Marketing & Publicity
> >>
> >> -
> >> 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: [ASF M & Conferences] Community Over Code logo for project sites

[sebb]

On Tue, 15 Aug 2023 at 18:55, Brian Proffitt  wrote:
>
> All:
>
> ASF’s flagship event, Community Over Code, is happening October 7-10
> in Halifax, Nova Scotia (formerly called ApacheCon).
>
> I would like to ask all projects to add the logo and event URL to your
> project website to help the ASF promote the event - and thank you to
> projects who have already done this! Or, if you'd like, promote the
> event with the logos on your project's social media channels.
>
> Logos:
> https://apache.org/foundation/press/kit/#eventlogo
>
> Event URL:
> https://communityovercode.org/
>
> Thank you!
> BKP

There is already a standard way to do this, as is done by:

https://jmeter.apache.org/
https://commons.apache.org/
https://hc.apache.org/

and probably others that use Maven to build their sites.

They include a link to the event page:
https://www.apache.org/events/current-event.html
with an image such as
https://www.apache.org/events/current-event-125x125.png

The idea behind this was to avoid having to change loads of websites
before and after every event.
Instead, the event organisers can change the page content (or add a
redirect) and the various sized images accordingly.

By the way, the SVG and PNG versions of the logo look very different -
is that intentional?

> Brian Proffitt
> VP, Marketing & Publicity
>
> -
> 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: Updates to Project Media Guidelines

[sebb]

On Mon, 14 Aug 2023 at 18:44, Brian Proffitt  wrote:
>
> The M team announces some new resources for TLPs and Incubator
> projects to use when they need assistance on marketing and publicity.
>
> Available today are a new collection of guidance pages in the ASF M
> wiki space[1]. This collection of pages includes

Note that this part of the wiki is private and requires a login.
All ASF committers should have access using their normal credentials
(if not, contact Infrastructure).

> Publicity Guidelines for Top Level Projects
> Public Relations Services
> Incubator Graduation Services
> Blog Submissions
> Social Media Services
> Brand Services
>
> The content for the first page, "Publicity Guidelines for Top Level
> Projects," formerly resided on apache.org[2], but now has been linked
> from there instead. This follows the general shift to use apache.org
> as an external-facing information site for the public and getting
> useful "documentation" for ASF participants on the wiki or
> community.apache.org.
>
> We look forward to adding more helpful content in the days to come.
>
> Peace,
> Brian
>
> [1] 
> https://cwiki.apache.org/confluence/display/PRESS/Marketing+and+Publicity+Home
> [2] https://apache.org/press/
>
> Brian Proffitt
> VP, Marketing & Publicity
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

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

[sebb]

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

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

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

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

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

[jira] [Commented] (COMDEV-531) Unable to submit report via reporter.a.org

[Sebb (Jira)]

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

Sebb commented on COMDEV-531:
-

Once the agenda file contains an invalid UTF-8 character, it looks like all 
subsequent updates by Whimsy will fail.

 

As to the lack of error info shown by Reporter, that is what this issue is 
about.

If Reporter gets an error from Whimsy when submitting an update, the app needs 
to show sufficient info to the user to be able to investigate further. This may 
possibly involve changes to the Reporter-Whimsy interface, but I think the 
starting point needs to be at the Reporter end - hence this issue.

> Unable to submit report via reporter.a.org
> --
>
> Key: COMDEV-531
> URL: https://issues.apache.org/jira/browse/COMDEV-531
> Project: Community Development
>  Issue Type: Bug
>Reporter: Philipp Ottlinger
>Priority: Major
>
> When I tried to file the Creadur report I was able to properly edit the 
> report, but when hitting "Publish via Whimsy" all I get is:
> "Something went wrong, and we couldn't publish your report.
> Please check with the Whimsy tool to see if there is already a report posted!"
> Not sure what else to add ... thus so unspecific.



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