Document CoreDev organization #27497

They have been attempts and discussions in the past to document other aspects of project culture such as maintenance with #25560. The organization of in-person events can be itself a source of contention, and I'm speaking here as a former organizer. While it's voluntary like all other tasks in Bitcoin open-source, there is a lot of subjectivity in the choice of schedule, place and the selection of attendees. Documenting such process will bring more transparency and ensure there is basic accountability of the organisers.

Beyond, this should minimise CoreDev becoming a tool to discriminate some contributors without legitimate or legal ground, or being used as part of a corporate or cultural capture agenda of the project.

I don't think a project software bug tracker is the right place to discuss this.

Agreed. As someone who has been invited and then abruptly disinvited from these without an explanation of why I do think the secrecy around these is convenient for those who want to push certain agendas or push certain individuals away from contributing to the project. But I think it needs to be a separate repo for organizing and discussing events rather than within this repo. There has to be a cut off for invites and directing that discussion to this repo doesn't seem ideal to me.

Going to close this, as I don't think it's the right place for this discussion, it's not really clear what the outcome should be.

@fanquake Without a desire to make more noise here, just to clarify your position you think it's not a discussion we should have as a project or it's more the unclarity of the outcome ?

For the place, of course there is https://github.com/coredev-tech/coredev-tech.github.io which might a better place. Just no contributors are looking on this repository.

For the outcome, we could have a COREDEV.md, detailing the process:

• reach out to past organisers to check if there is someone already working on it and have access to the organisational templates
• reach out to a substantial numbers of contributors to see if the schedule can work.
• send a survey to people if the location works.
• give heuristics on which we're inviting people.
• make clear a conflict resolution process if organisers think someone should be de-invited at the last minute (and for sure you can have good reasons for doing so e.g non-respect of confidential operational information).

Beyond, if you take as an example the IETF they do have a lot of formalisation of their process especially to ensure a multi-stakeholder approach in the development of Internet standards, see https://www.ietf.org/archive/id/draft-nottingham-avoiding-internet-centralization-05.html#name-multi-stakeholder-governanc. I know "corporate capture" or "cultural capture" can be seen as strong words, I don't lend to anyone "bad intentions", it's just you have a diversity of cultural leanings and interests among the project contributors and this something we should encode in our process, in my humble opinion.

I can understand from a maintainer viewpoint the concern of turning the project as a bureaucracy, where people are going to spend more time to object to each other excerpts of our process documentation rather than getting shit done, coding and reviewing. And it was quite my concern to not get involved with #25560. So I think it's more a matter of finding a balance, where should be this balance ? I don't know though would be healthy to have a discussion about it.

(As I been asked offline, no I've not been de-invited from upcoming CoreDev, this is just to avoid future abuses and open the pool of organisers to seasoned contributors who might not have operational know-how)

Without a desire to make more noise here, just to clarify your position

There's no problem with having any discussion about how to organize a developer meetup, I just don't think having it in this issue tracker is the right place, or going to be particularly productive.

Okay, I'll propose a document draft during the coming future to make things more productive. Sorry for the issue tracker usage, unclear where "meta-discussions" should go between the mailing list and here.