TL;DR; Maybe time to get the discussion to some concrete proposals and
directions - I have - by the end - a concrete idea what maybe (?) we could
do to turn this discussion into something tangible and executable.
Piotr:
> [...] make the public aware that if
> they don't start contributing to a "dormant/at risk" sub-project (e.g.
> Flume), the sub-project will reach EOL.
Gary:
> Trying to match the LTS concept as examplified in tha Java world by the
JDK
> itself or Ubuntu is silly IMO: These products are backed by large
companies
> with large contract$ with customer$ that require multiple years of
> predictable runway. That's just not Apache, much less Commons IMO. That
> said, each PMC is free to create its own policies for support, which is
> great. I'm not sure we need to go beyond that.
Giles:
If "Commons" stays too long in the past (wrt the evolution of the
> language it purports to use), it will die.
>
I think I would agree with all that.
Yes, I see the need to standardise our "messaging" towards the users when
it comes to "state" of each project and release - so Piotr starting the
thread is very right that - I think - we should do "something. Currently
it's not at all obvious and "common" for our users of all Apache software
to know what to expect.
I think all this thread is about is "setting common expectations about
status of the project's <line of development> for downstream maintainers
and users".
There is also nothing wrong with project "dying". This is normal and
expected that each project will - sooner or later - die. The fact that
there is a single person maintaining some part is a good sign that the
project actually SHOULD die. And our role as the ASF is to make sure that
this is communicated to our users in a consistent way and that we manage
the "dying" in the way that it has least impact on them. That's IMHO one of
the most important things the foundation does - sets the right expectations
for our users, so that they can rely on them - whatever the expectations
are.
Now - the question is who and what and when. I think the discussion here is
super interesting but we still do not have a common idea what should be the
outcome.
But ...
Maybe I have one suggestion.
We know we cannot overburden the "already understaffed" PMCs with extra
work and building processes and communicating that, describing it, and
especially making changes in how they work. That's already far too much and
we will not achieve anything if we try to modify processes of the PMCs at
"bulk".
So really the question here is - who will do the work to improve things (if
we want to improve)? Should that be policies that we will throw at the PMCs
to follow? Recommendations? Tools? Who will write the tools? All those
questions should be asked (and answered) if we want to make a concrete
outcome other than have a nice (or not so nice) discussion.
I am a big proponent of leaving freedom to PMCs on how they work, and also
I am a long time proponent (and I proposed this at various occasions) of
not introducing new processes and effort on projects to "do stuff" but
rather tie-in in the processes and "burden" they already have - ideally
adding stuff to do for PMCs that has a clear incentive to the PMCs while
removing some other stuff and explaining why we are doing it.
So maybe a good proposal (not immediately actionable but one that could be
started and lead to completion eventually) is to plug into the initiatives
that are already running:
1) we know (those who follow board actions) that the board is currently
experimenting with changing the format and scope of the board reports. The
idea is to have more information that is actually 'useful' in those reports
- one that people will not feel that they are sending it and it's not used
or looked at, but also one that will allow board to make better decisions
2) we also know (those who follow board discussions) - that we are looking
to hire a "tools" person that will work on "board-tooling" mostly - i.e.
making sure (not necessarily implementing themselves) that tooling that
will be used by the foundation at the "board" level is actually evolving
and become more useful (mostly around upcoming challenges with CRA but also
board reporting tools etc.)
Now - of course we do not have the power of decision making in either of
those initiatives, but maybe we could propose something for those who have.
For example a small set of the most important (machine readable as well as
human readable) status information that the PMC members could very easily
report on for the board followed by a tooling that will expose the
information on "ASF" levele.
It could be a nice way to not only define "common standards" but also a way
to "keep the data maintained" (by the means of updating the information
during the quarterly reports by each PMC).
Example (people love examples): List your active "lines" of your software
and assign a state "ACTIVE, BUGFIX ONLY, SECURITY ONLY, EOL". This is very
similar to (recently introduced in reports) state of the whole project
("ACTIVE, DORMANT, NEAR ATTIC, ...").
That could define a nice "common" interface that each project could "map"
their approach into - without them having to adapt or change their
processes. And it could be eventually used to produce a single page where
each project of ASF shows the "status" - not only for the whole project but
for all the "lines of development" it has.
Not sure if this is a good idea - it might or might not be. It might or
might not be accepted or understood by the board why we might want it. The
"tool" person must be hired and VP tooling should set it as a priority for
that person to make it happen. Lots of uncertainties.
And PMCs should maybe be given something to "take away" from the report -
so that they are not seeing it as "again new reporting obligations we have"
- simplifying and making the reporting faster and easier and knowing that
what you report on will actually be useful, might be a good explanation and
incentivisation for PMC members to do it
But I think the first step is to agree to this - or another - proposal that
we can agree we have consensus on so that we can move on with the
discussion to the execution phase.
J.
