I think overall 3 strategies could be taken to design a conflict resolution system when there exists a higher and lower authority (e.g. the ASF and individual Apache projects):
(1) Only the higher authority can publish bylaws. No other supplemental bylaws are permitted in the lower authority. This seems like the direction ASF prefers right now, since it is recommended that each project should only have guidelines, not bylaws. (2) The lower authority can publish bylaws, but must not conflict with the bylaws published by the higher authority. This is naturally difficult to achieve, since the lower authority bylaws require higher authority review during publication, and higher authority needs to review all lower authority bylaws when updating or adding new bylaws to make sure everything is still compliant. It is a lot of operational burden. (3) The lower authority can publish bylaws, and can conflict with the bylaws published by the higher authority. However, during evaluation time (e.g. when a conflict happens in a specific project), the higher authority bylaws supercedes the lower authority bylaws. Individuals in the conflict can use the higher authority bylaws to invalidate the related lower authority bylaws. This seems to be the most flexible solution, since it allows both authorities to evolve independently, and only reconcile with each other when necessary. The approach seems to be used pretty widely in legal systems, such as the federal preemption rule used when resolving conflicts between United States federal laws and state laws. This looks like the direction that Carl is advocating for (correct me if I am wrong), which I think makes sense in general. Best, Jack Ye On Wed, Jul 3, 2024, 4:47 PM Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > By the point of time, the Incubator guidelines were introduced: > - Projects were strongly encouraged not to have bylaws and to use what was > documented in policy > - If they wanted bylaws, they should call them guidelines > > The reasons for this include that bylaws cannot cover every situation, and > just about all of our policies are in fact guidelines not bylaws. If a > project has a good reason for doing something differently than is > documented, they can do that. > > I don’t have the time right now, but if you search the archives, you > should be able to find conversations about this. > > Kind Regards, > Justin > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
