FreeCAD Contribution Process

[wmayer]

don't we have github to gitlab sync enabled? If I'm not mistaken it's possible to merge something on gitlab and it'll auto sync with github, so one possible alternative is to allow creating merge request on gitlab and merging there.

A commit made on GH will appear in GL after a while but I don't know if this works the other way around. For instance, I wonder what will happen if two people merge a PR/MR at the same time on the two platforms.

[Roy_043]

IMO, this shouldn't be mandatory.

So what is then an 'agreed-on problem'?

agreed-on problem

[paddle]

Because right now my PR are sitting idle seemingly forever.

issue #7695

Thanks.
For contributors it indeed feels a bit lonely. It's like you make the stuff, post it and then nothing happens and you don't know what to do. Who to ask.
By the way, any of the PR I mentioned trigger an interest for you?

[adrianinsaval]

Nobody is infallible. What is the procedure if a PR is wrongly rejected?

reopen the PR (or make a new one)? do you think this should be written down? do you have suggested text?

[chrisb]

Nobody is infallible. What is the procedure if a PR is wrongly rejected?

reopen the PR (or make a new one)? do you think this should be written down? do you have suggested text?

The main probem would be how to identify that it was wrongly rejected. I would guess that contributors rather give up than retry.

[Roy_043]

do you think this should be written down?

I am not sure. The proposed rules do seem a bit one-sided. Obviously I understand the need for control, but some of the conditions can also discourage volunteers.

Example:
https://forum.freecadweb.org/viewtopic.php?f=10&t=73107

Do I need to create a GH Issue and seek approval from one of the devs before I can make a PR? Note that nobody seems to care enough about this post to respond. So it could sit in a GH queue for a long time then. Do we really need (want) this overhead for something that is relatively trivial? And if I do get PR permission and find another minor issue while working, do I really need to create a separate PR and start the same approval procedure again?

[mlampert]

14. Maintainers SHALL NOT make value judgments on correct contributions.
15. Any Contributor who has value judgments on a PR SHOULD express these via their own PR.

Could somebody add some context to these two points please? I'm not sure I understand what this means and what the value/intent is.

[sliptonic]

14. Maintainers SHALL NOT make value judgments on correct contributions.
15. Any Contributor who has value judgments on a PR SHOULD express these via their own PR.

Could somebody add some context to these two points please? I'm not sure I understand what this means and what the value/intent is.

This came up during the discussion on the github pr. Took me a while to find it. I'm sure there's a way to search resolved conversations but I haven't figured it out.

Ideally, the maintainers are not judging the value of the contribution or even the quality of the code. They are enforcing process. Code quality is enforced by unit tests and encouraged/improved through code review.

Decisions about the 'value' of the contribution should be pushed upstream to the issue where it is entirely appropriate to discuss whether a problem is worth solving.

What is a "value judgement"?

A judgment about the value of the contribution. FOSS projects can suffer from holy wars where someone wants to make a change but someone else doesn't think that change is worthwhile. (GUI stuff can often go this way)

The intent of this 'rule' is to avoid those altogether. Otherwise, the person with the most authority wins even if their judgment is flawed.

This really only works if there's a good 1:1 relationship between problems and solutions. Then the 'value' is discussed thoroughly in the 'problem', ideally narrowing and focusing it. Then the solution is only judged on whether it resolves the problem.

[wmayer]

Ideally, the maintainers are not judging ... the quality of the code.

Why not?

Code quality is enforced by unit tests and encouraged/improved through code review.

Unit tests enforce the correctness of the code but not its quality because bad written code may still pass all tests. And who does the code review if not the maintainers?

[Zolko]

Decisions about the 'value' of the contribution should be pushed upstream to the issue where it is entirely appropriate to discuss whether a problem is worth solving.

This is fundamentally important if we don't want us to spend our time in bike-shedding. But how do you define and quantify this ? As an example, look at Paddle's workbench selector thingy:

Gui: Add option to show workbench selector in menu bar #7679
Simple +-100 line commit adding a setting. Up for the grab !
https://github.com/FreeCAD/FreeCAD/pull/7679

it's a "solution " to a non-existing problem, but because of people's politeness to not hurt feelings he wastes his time with this. In this example, there is no problem, but still a PR. How do you propose to deal with it if not by closing manu-military such PRs as without "value " ?