FEP-0008: Project Group Structure

[kadet1090]

FreeCAD, as a project, has not historically had a well-defined management or responsibility structure. Over time, however, some structures have organically emerged in the form of Working Groups. This document formalizes how such groups are created, how they operate, and what their responsibilities and limitations are.

Many developers and users find the organizational structure of the project confusing. People are often advised to consult groups like DWG, CWG, or CQWG, but there is little information on what these groups do, how to contact them, and who their members are.

Historically, all development decisions were made by the Maintainers in dialogue with the community. This worked when the project and its community were relatively small, and everyone could keep up with all discussions. Today, however, the size of both the project and its community has outgrown this model, and it is no longer feasible to rely solely on Maintainers.

Over time, some groups have formed organically. For example, the Design Working Group (DWG) grew out of a few community members active in UX/UI. Since that group was already operating de facto, Maintainers decided to treat it as an advisory body.

The lack of clear information about these groups has become a barrier to entry and a source of frustration for both new and existing contributors who are not always aware of the latest developments. This document aims to formalize the current structure of these groups and answer key questions:

1. What Working Groups exist?
2. How are groups structured?
3. How can someone become a member of a group?
4. Where can the current membership of a group be found?
5. What are the tasks and non-tasks of these groups?
6. How do these groups operate and communicate?

This document is intended to be a living standard and will always reflect the current state of the Working Groups.

Important Links

• 🔍 rendered proposal: FEP-0008: Project Group Structure
• 💬 official discussion: FEP-0008: Project Group Structure #22

[Reqrefusion]

I believe some additional information regarding conflicts of interest could be added. It should also emphasize that maintainers are solely responsible for the decisions made. Working Groups do not assume any responsibility.

[kadet1090]

I believe some additional information regarding conflicts of interest could be added. It should also emphasize that maintainers are solely responsible for the decisions made. Working Groups do not assume any responsibility.

Agreed, do you have any specific kinds of such possible conflicts of interest in mind?

About the groups - I wrote that groups are advisory bodies, and the final decision is solely in the maintainers responsibility. Isn't that enough? I can reinstate it within working groups section to reinforce it.

[Reqrefusion]

I've added a few things. I'm thinking of adding a few more things about conflicts of interest.

[Reqrefusion]

Additionally, each group must specify the method and location of applying for membership.

[kadet1090]

New members of the working group are appointed by the Chair. Community member may request membership by contacting the Chair or asking over public channel. The Chair can accept or deny such request - in such case however the Chair should provide rationale for the decision, for example lack of required expertise. Not being a member does not however forbid anyone from taking part in the discussions.

That is pretty clearly stated though.

[Reqrefusion]

I've added a few things for clarity. The writing here is superficial and open to initiative. I support taking initiative, but the membership process should be clearly stated.

[kadet1090]

I'm more in favor of group being self organizing and leaving them with a lot of freedom with the process. The process is really take initiative and get noticed, someone will contact you - all groups that I am part of are quite good at it. If for some reason someone thinks that they do everything that is required and no one approaches them - then they can contact the chair by any available means.

Working Groups should consist of members that are in the group because they do things related to the group area of interest and are trusted to do that, not do things related to the area of interest because they are in the group. I fail to see how making that process more formalized would bring any benefit to the project. Although, your suggested change in PR is ok.

[Reqrefusion]

If it were as you say, this document wouldn't be necessary. It's being added to ensure that outsiders can see the groups as public. Our goal here isn't to provide more benefits to the groups, but to address concerns about the groups within the community.

[kadet1090]

That part was never raised as concern and it is documented in the document. Previously nothing was said about it - we should not overshoot the goal because that can do more harm than good.

[Reqrefusion]

Also, should there be a forum-related obligation in some cases? Because the forum is truly a platform under our management, along with the wiki.

[kadet1090]

I don't think so, the official communication should happen on GitHub because that is a platform where development of FreeCAD happens and there should only be one official and required place.

[Roy-043]

In case of a 'rough consensus' some additional information should be provided IMO. For example, if two options were considered and full consensus could not be reached, then presenting both options would be better than presenting a 'united front'.

[Reqrefusion]

I think it was done this way to leave some initiative.

[kadet1090]

Yes, the summary should contain both, including the "votum separatum" - like "Some members were concerned about ...". AI should do pretty good job in that regards, but we should focus on capturing the majority rather than separate votes.

[kadet1090]

@Roy-043 #23 (comment) - does that suggestion cover your concerns?

[Roy-043]

That is fine, thank you.

[pieterhijma]

The document looks very good to me overall. I'm circling back a bit to the discussion of last developer's meeting regarding "inclusivity" of the working groups. I'm pleased to see that this is already pretty well defined in the proposal, quoting:

Groups may choose their preferred communication tools, but the chosen platform must allow free participation without barriers such as payment or special permissions. The method should be as transparent as possible, ideally allowing read-only access without requiring an account.

However, I believe that none of the current working groups satisfy this requirement because of the use of discord. In fact, I believe that only discussions on the forum could satisfy this or perhaps Matrix if you want to be able to do real-time discussion as on Discord.

So, I agree with the document and hope it stays in but I also realize that we then may need to discuss the access that we currently provide.

[Reqrefusion]

You can also have read permissions on Discord without requiring an account. However, this requires setting up.

[pieterhijma]

I'm not aware of that. Could you provide some documentation on how to do that then?

[kadet1090]

I'm working on a bot that will publish logs from discord so they are publicly readable which should address your concern.

[pieterhijma]

Ah right, that would be good to have.

[pierreporte]

I’ve finally forced myself to reat the FEP proposal. It sounds pretty good.

To complete the CWG part:

• List of member is here: https://github.com/orgs/FreeCAD/teams/cad-working-group
• Communication: like DWG, but with the relevant discord channels
• Tasks to add:
  • Participate actively in working group discussions
  • Research standards that FreeCAD should alow users to follow
  • Research common features in existing programs that are missing in FreeCAD
• “A member should” section: same as DWG
• Membership requirements: strong CAD experience, preferably in the industry and with multiple CAD programs