Bylaws patching or refactoring?

[Vincent de Lau]

Hi all,

Having dealt with the intricacies of the FIG bylaws over the last couple of years, I'm going to start an initiative to propose some bylaw changes. However, I'm a bit on a cross-road as to what direction to take it. I'm putting these thoughts out into the public to test the waters and to decide what next step to take.

My initial plan was to just propose a set of 'patches' to fill in some gaps and to fix some inconsistencies. However, I have a feeling that when I ask for input on other needed patches, there will be some discussions on more fundamental aspects of our bylaws and the way we operate as a group.

I have to admit that I can see that there may be a need to make some more fundamental changes to the way the FIG is organized. I see a lot of inactivity and I feel the FIG lost it leadership role in the community over the years. So, the other fork in the road would lead me in the direction of proposing changes like the following:

- Reduce the role of the Core Committee to a more technical role, focusing on the quality of the output of the group (PSR, PER, utilities etcetera). The number of CC seats could be reduced.
- Introduce two types of membership, Projects and Individuals. Membership requires participation, and inactive Members would automatically loose their membership. The process for becoming a Member should be simplified. Ideally qualification and participation requirements are quantified and measurable.
- Give the responsibility of the Groups organization to the Members. Membership, bylaws changes and nominations would no longer require a CC vote.
- Significant (non-technical) decisions on the FIG would be the responsibility of the Member Projects and would be voted on by Project Representatives.
- Other decisions and initiatives may be voted on or introduced by Individual Members. CC members, Secretaries and Project Representatives would be allowed to also be an Individual Member. Current Working Group members would automatically qualify to be an Individual Member.
- Decouple Working Groups from the Editor and Maintainer roles. A Working Group could be responsible for multiple artifacts, or may be formed for a completely different purpose like maintaining the FIG website.

Is this a route we would want to explore?

Kind regards,
Vincent de Lau

[Vincent de Lau]

On Saturday, October 7, 2023 at 4:38:39 PM UTC+2 Vincent de Lau wrote:

My initial plan was to just propose a set of 'patches' to fill in some gaps and to fix some inconsistencies. However, I have a feeling that when I ask for input on other needed patches, there will be some discussions on more fundamental aspects of our bylaws and the way we operate as a group.

I have to admit that I can see that there may be a need to make some more fundamental changes to the way the FIG is organized. I see a lot of inactivity and I feel the FIG lost it leadership role in the community over the years. So, the other fork in the road would lead me in the direction of proposing changes like the following:

 

Is this a route we would want to explore?

Hi all,

This discussion had some follow up on Discord [2], where there was not a lot of traction to do a big overhaul. As such, I'm going to make smaller proposals on specific areas. With the current vote on the election cycle fix ongoing, I'm going to work on two further proposals:

The first is on cleaning up and clarifying the language for the various voting protocols. Specifically, I'd like to address the following tensions I have:
- Remove some of the duplication of language, especially for the combined CC and Project votes.
- Clarify the language around 'calling a vote', to make a distinction between 'requesting a vote to be organized' and 'organizing a vote'. Requesting a vote is probably up to the person preparing the proposal, when they believe the proposal is ready. Organizing a vote is something that may always be requested of Secretaries. In simple cases, a vote could also be organised by and Editor, Maintainer, CC member, or Project Representative.

The second topic is improving the language and procedures around Working Groups, Editors and Maintainers. This is also in line with some of the remarks I made during the introduction of the PER discussions [2].

- Decouple Working Groups from the Editor and Maintainer roles. A Working Group could be responsible for multiple artifacts, or may be formed for a completely different purpose like maintaining the FIG website.

- There are some gaps in the procedures around the Maintainer, especially when the position is vacant. I intend to add some language to the PSR workflow bylaw what to do in that case. For instance, how to deal with a bug-report or PR for an Accepted PSR without a Maintainer?

If you have any ideas or concerns around these to topics, I'd welcome any feedback here or in the #fig-bylaws channel on Discord [1]

--
Vincent de Lau

[1]: https://discord.com/channels/788815898948665366/1160915782386057228
[2]: https://groups.google.com/g/php-fig/c/gLNKg9jpRCU/m/vA6YbWnzGAAJ

[Larry Garfield]

On Wed, Jul 17, 2024, at 5:04 PM, Vincent de Lau wrote:
> On Saturday, October 7, 2023 at 4:38:39 PM UTC+2 Vincent de Lau wrote:
>> My initial plan was to just propose a set of 'patches' to fill in some gaps and to fix some inconsistencies. However, I have a feeling that when I ask for input on other needed patches, there will be some discussions on more fundamental aspects of our bylaws and the way we operate as a group.
>>
>> I have to admit that I can see that there may be a need to make some more fundamental changes to the way the FIG is organized. I see a lot of inactivity and I feel the FIG lost it leadership role in the community over the years. So, the other fork in the road would lead me in the direction of proposing changes like the following:
>
>> Is this a route we would want to explore?
>
> Hi all,
>
> This discussion had some follow up on Discord [2], where there was not
> a lot of traction to do a big overhaul. As such, I'm going to make
> smaller proposals on specific areas. With the current vote on the
> election cycle fix ongoing, I'm going to work on two further proposals:
>
> The first is on cleaning up and clarifying the language for the various
> voting protocols. Specifically, I'd like to address the following
> tensions I have:
> - Remove some of the duplication of language, especially for the
> combined CC and Project votes.
> - Clarify the language around 'calling a vote', to make a distinction
> between 'requesting a vote to be organized' and 'organizing a vote'.
> Requesting a vote is probably up to the person preparing the proposal,
> when they believe the proposal is ready. Organizing a vote is something
> that may always be requested of Secretaries. In simple cases, a vote
> could also be organised by and Editor, Maintainer, CC member, or
> Project Representative.

These seem reasonable; let's see what you come up with. :-)

> The second topic is improving the language and procedures around
> Working Groups, Editors and Maintainers. This is also in line with some
> of the remarks I made during the introduction of the PER discussions
> [2].
> - Decouple Working Groups from the Editor and Maintainer roles. A
> Working Group could be responsible for multiple artifacts, or may be
> formed for a completely different purpose like maintaining the FIG
> website.

I'm not sure here. What problem is being solved? A WG needs to have a person in charge where the buck stops. As does an artifact. We can already have one WG responsible for multiple PSRs, PERs, etc. (We already have, I believe.)

> - There are some gaps in the procedures around the Maintainer,
> especially when the position is vacant. I intend to add some language
> to the PSR workflow bylaw what to do in that case. For instance, how to
> deal with a bug-report or PR for an Accepted PSR without a Maintainer?

Presumably this falls back to either the CC or Secretaries. I think the bylaws say CC right now, but if not, we can make that explicit.

--Larry Garfield