Hi, Long time lurker on the list, I am not super familiar with all the intricacies of the boost libraries. But if you need someone, I think I can write some sort of scripts and attach them to CI which periodically generates these reports for various boost libraries. Regards Rishabh Rawat Regards Rishabh Rawat On Mon, Apr 18, 2022 at 12:21 AM René Ferdinand Rivera Morell via Boost wrote:

On Sun, Apr 17, 2022 at 11:14 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

The C++ Alliance is receiving many applications with qualified C++ candidates, but we are having a hard time matching them up with long-term projects which are aligned with our organization's goals.

Is there a list of libraries that need help or does anyone know of one or more particular libraries that are in need of improvement and work?

It would be great to have someone to evaluate and direct, long term, which libraries need maintenance help, what kind of help, and manage the people doing the work. Previously this was something that the Community Maintenance Team would oversee. But it doesn’t appear that the CTM is active any longer. More concretely it would be great if someone(s) did the following:

* Look at last commit times in the sources of the libraries. * Look at the outstanding PRs in the libraries. * Look at the reported issues of libraries. * Find other metrics to evaluate under-maintained libraries. * Point people to those libraries that need help.

-- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

Hi, Long time lurker on the list, I am not super familiar with all the intricacies of the boost libraries. But if you need someone, I think I can write some sort of scripts and attach them to CI which periodically generates these reports for various boost libraries.

That would be fantastic! No need to ask for permission to do that. I'd say go ahead and do what you think is best. For example, I took it upon myself to do the inter-library cycles report. Anything like that, which can show in simple terms the information, would be very beneficial.

+1. Boost.Config has a very complete (maybe too complete for most libraries) set of CI tests if you need something to copy - probably trimmed down a bit though for most libs. If you get stuck with PR's not running their actions because you're a first time contributor, ping myself or Rene and we should be able to kick those off.  Likewise if you get stuck fixing any issues that crop up. And thanks! John.

On Sun, Apr 17, 2022 at 1:08 PM John Maddock via Boost < boost@lists.boost.org> wrote:

I've often thought, that what Boost really needs is a "janitor".

I remember doing janitorial duties for some years :-)

The Janitor is someone who's qualified to mend just about anything that breaks, doesn't mind doing the boring jobs that no one else what's to do (at least not in their free time), and is willing to be told by others what jobs are the next priority. In the context of Boost that would mean something like:

1) Determine which libraries are being actively maintained.

2) Make sure all libraries have decent tests and CI running (yes, even the maintained ones, though they would be lower priority).

3) Make sure all libraries are still fit for purpose, and propose libraries that should be deprecated and removed from Boost, then Sheppard them through the procedure.

4) Where general purpose libraries need maintenance, work through the PR's and issues, plus any issues shown up during the addition of enhanced CI. The priority for which libraries to work on next should be decided by feedback on the mailing list (ideally it should be possible to vote on it, but we don't have the infra-structure for that yet).

5) Report back to the mailing list at regular intervals so folks know what's happening, and can help identify the next target for maintenance.

6) Be prepared to engage in some "emergency maintenance" when required, as in "library X has a showstopping issue and the maintainer is out on contract in Ulaanbaatar".

7) Where highly domain specific libraries need work (Graph!), agitate and cause general mayhem until someone with the right experience steps up to the plate and at least gives them a bit of modernization.

Of course the "janitor" need not be one person, and no one person need be the designated janitor for life! :)

Right.. But we are looking for someone to be the superintendent. Managing subordinate janitors who do most of the work. As the C++ Alliance is funding some of the subordinate janitors :-) -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On 17/04/2022 19:08, John Maddock via Boost wrote:

I've often thought, that what Boost really needs is a "janitor". The Janitor is someone who's qualified to mend just about anything that breaks, doesn't mind doing the boring jobs that no one else what's to do (at least not in their free time), and is willing to be told by others what jobs are the next priority. Before any of that, it would be great for somebody to go through all open issues in all boostorg libraries, see if the bug is valid, if it is score it for priority.

Once all open issues have been triaged and priority scored, then a work queue can be formed based on how many Boost users are negatively affected by the issue. Publishing a "bug impact" score per library would be super useful to aid end users not locking themselves into a known-buggy library and then finding nobody will even look at issues they open. This is bread and butter stuff we've been sorely lacking for decades in the case of some libraries. I remember doing an age-weighted ranking of open issue count per library years ago, and it wasn't the libraries you'd think we came out on the top. Niall

On 18/04/2022 19:58, John Maddock wrote:

One of the things I miss in GH is the ability to downgrade an issue while still keeping it open - so for example I tend to keep "nice to haves" and "feature requests" open even though there's no real intention to do anything about them at this moment in time.

You can put labels on issues to indicate that they've been triaged as "nice to have" or whatever. You can then use these in searches, or just let your eyes be drawn to whichever label colour you're currently interested in. You can also set up templates for bug reports and feature requests (or other things) such that they automatically get appropriate labels, that can then be later triaged further if desired. For the ease of automated reporting tools like someone was suggesting in another thread branch, it may be useful to standardise on a basic set of labels Boost-wide, though these could still be augmented as needed for specific libraries (provided the custom labels are used in addition to the generic ones).

On 18/04/2022 04:19, Ivan Matek via Boost wrote:

On Sun, Apr 17, 2022 at 6:14 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

Is there a list of libraries that need help or does anyone know of one or more particular libraries that are in need of improvement and work?

I wish somebody took a look at bimap. IIRC even simple stuff like support for initializer list is missing and MRs for adding that are ignored. https://github.com/boostorg/bimap/pull/31 I know this is a tiny lib, but I have actually used in in prod in past 5 years, so it is not super obscure.

Haha, I was just wondering about that one - it has actually had some community maintenance for basic bug fixes over the years, but I see no commits from the original author in the GH commit logs. So yes, this is a good example of some "low hanging fruit" that could make better use of modern language features. Don't forget to file a feature request on GH though!  ;) John.