On Thur, Aug 1, 2024 at 6:37?AM Vinnie Falco via Boost < boost@lists.boost.org> wrote: On Wed, Jul 31, 2024 at 1:52?PM Kristen Shaker via Boost < boost@lists.boost.org> wrote:

...let the developers make a decision on how they would like to proceed

Thank you, and this is very much in the Boost tradition. While the Boost Software License is likely to be the project's most impactful contribution, the Formal Review Process is a close second. Therefore, I propose that the question of custodianship be decided by a formal review. It is becoming more and more difficult to find suitable review managers who are not associated with the C++ Alliance (a self-inflicted wound, I suppose) but I nominate these as candidates: Ion Gaztanaga John Maddock Thanks ------------------------------------------------------------------------------------ I understand the desire to use something like the review process for this, but I think we need to be cautious about the differences between a software review and what we need in this case. Not that there is no way to do something similar to a review, but just to make sure we understand what the review process is good at and not good at. The intent of the review process is to let interested developers share ideas and expertise to find the best technical solution. The proposed library is the focus of the discussion but in some cases the conversation can range far from the proposal. The allowed outcomes include fully accepting the proposal, provisional acceptance with stipulations, or rejecting the proposal with constructive commentary about how it could be improved to have a more positive reception. All the participants on this list know this, but consider how the review process compares to what is needed in this conversation. We're trying to solve organizational and legal issues, instead of implementation and documentation issues. We want to decide what path would best allow us to proceed with our core tasks of producing high quality, real world usable libraries for inclusion in a broad spectrum of software uses, leading to refinement of implementation and interface so we can have a solid proposal for inclusion into the C++ standard. What organization would give the work we do the needed visibility so developers and companies around the world want to try the Boost libraries? What leadership would give our developers sufficient insight into the needs of C++ developers at large required to provide for those needs? What what resources will allow us to solve the technical and legal issues in our structure and infrastructure that we need to continue to mature and grow effectively? These aren't questions I personally have the technical and organizational expertise to judge well. Nor are they questions that someone could provide a sample implementation for during a review to illustrate a potential pitfall. They are however questions where some members have a strong personal stake and contention could cause lasting and damaging rifts between the volunteers that are the heart and soul of Boost. It is also true that reviews tend to have just the three outcomes listed above, while this process could come to conclusions no one has even thought of to mention, yet. I also think that to be useful it will need extensive involvement from as many Boost participants as possible. You can have a good technical review of a library that is dominated by half a dozen experts in the problem and techniques to address it. This review will need input from half or more of the Boost community to produce the broad buy in that such organizational decisions should get. This is again not to say it can't be done. I am only trying to make sure that we understand the possible ways a review of this sort will be far different from the normal reviews we perform. John Phillips Review Wizard