To counter this point:
> But the present organisation looks defunct. There’s no strong leadership.
A lack of central-ised leadership is a good thing
If this is their only reason for calling the organisation defunct then this point is invalid however I am unsure if this is where the critique lies
In that spirit i am pondering how something akin to central leadership mandating such a change occur in this environment.
The biggest concern I can think of about doing something like this and degrading existing workflows would be alienating developers who prefer the existing methods and perhaps had a hand in making them what they are currently.
A lot of people in a company would likely grumble about such a mandate as a way of getting over it.
I guess here some examples:
- consensus could be tried for in a formal polling process and it be worked on post consensus
- one could also do the work and propose it then to dispell any concerns of achievability but at the risk of it not being used
- one could also try building an approach in which the project would gradually fade into a state where both options are viable, and then perhaps, should consensus be reached then, the project could fade into a state with solely the changed tooling
example stages:
- current tooling
- git repo-s mirrored, chat channel-s bridged
- facilitate project interaction on new git hosting method ( issues, mr-s, ...)
- fade towards solely using the consensus desired tooling
I think consensus is more suitable to large decisions than voting when maintenance of the group boundary ( guix devs) and maintenance of the number of states ( a set of tooling with only one tool per use case ( savannah or gitlab, matrix or irc, ...)) is desired
an issue like this could cause a split and sometimes that is ok
but when that is undesirable, if the one resulting state is formed then a continuous discussion process to form this one state into something which has the least cummulative "friction" is desirable.
whilst this may be slower initially than a top down mandate, those adapting to a top down mandate would have to adjust from what they are most comfortable causing slow down in the future
In defence of meta discussion, i think meta discussion is really just discussion where an assumed component is brought back into discussion.
I am new to the project as well, in my experience I have found the mailing lists to be quite fun, i havent submitted any patches to guix yet so i can not comment on that
perhaps an alternative could be mailing list propaganda to garner the excitement that currently surrounds something like discord
one trend i have seen with guix is the tendency to use existing technology with extensions to achieve ones means instead of using/ developing a technology which includes all desired features as standard, maybe this is a function of the older style
the irc and mailing lists are both publically logged and the system-s seem cohesive
the logs on irc are harder to read than scrolling up in something like matrix, also the lack of non-text media can be tricky