The FreeCAD Project Association

[obelisk79]

After a full review of all of the documents on github, I like how the start of this is structured and you are all collectively keeping things small in scope in these early days.

I will still express my feelings that one of the early orders of business should involve creating something along the lines of a 'development committee' to just formalize how development decisions and vision are made. There are clearly some delineations of who is who when it comes to feature additions and merge decisions and this would provide clarity on that point.

I don't suggest this as a means of there being a dictatorship, that of course is unhealthy for FOSS. Largely, what I'm speaking of already exists, but it is informal and unclear, this would merely organize things and help set realistic expectations for future would-be contributors. Just a thought, and I'm not trying to 'kick the dead horse' on this matter.

Thank you Yorik and the other FPA members who have commented in this discussion and debate. You have maintained composure and shown professionalism despite some of the more inflammatory remarks made, and that is great proof that the future of this project and its association is in good hands. I think some of the more emotional comments made by others, while inappropriate, are just an indication of how passionate this community is in seeing FreeCAD improve and grow.

[ragohix769]

Thank you Yorik and the other FPA members who have commented in this discussion and debate. You have maintained composure and shown professionalism despite some of the more inflammatory remarks made, and that is great proof that the future of this project and its association is in good hands. I think some of the more emotional comments made by others, while inappropriate, are just an indication of how passionate this community is in seeing FreeCAD improve and grow.

I quote and subscribe here.

[bleber]

I thing that a month report of the freecad status is a good thing to FPA.

[chrisb]

My point was that it is normal for one that is entering in a project to further develope code made but others, to have to make some efforts and to spend some time to grasp the logic. Time and difficulty will depend on the complexity of the software, on how well it is documented, on the possibility to ask for a clarification to previous developers ...

May be I have taken a bad example and that sliptonic code is so simple or so well documented that anyone can understand it from the first inspection. I have to admit that I have not looked inside but this particular code was not the real point.

If this is only general pondering, it's not worth mentioning, it's trivial. Sliptonics judgement was one of the best reasons I have read here, helping to understand why it takes so long to integrate realthunder's code. His code is far from simple The point is not that he found realthunder's code to be difficult to integrate, but that it was extremely difficult in comparison to other code submissions.

Nobody is happy that neither toponaming, nor other important PRs from realthunder are integrated yet (just to tell another triviality).

[sliptonic]

My point was that it is normal for one that is entering in a project to further develope code made but others, to have to make some efforts and to spend some time to grasp the logic. Time and difficulty will depend on the complexity of the software, on how well it is documented, on the possibility to ask for a clarification to previous developers

Per your earlier comment, you're not a software developer. A programmer, perhaps, Certainly a smart guy, but not a software developer.

A software developer's main job is to thoroughly understand the problem being addressed. That's more than just the problem at hand, it's also the context and nature of how that problem changes over time. A developer - a really good craftsman with experience - will create code that is more than a clever program. It's code that is:

Written to be maintained.
Has test cases
Conforms to generally accepted practices
Has good separation of concerns
Anticipates future features
Accommodates parallel work in other areas

When RT sent his contribution, it completely ignored all aspects of the current workflow. He may be a great programmer but he's no machinist and I doubt has ever worked in a CNC shop. His solution, while very effective at polygon offsetting ignored all kinds of realities about how CNC jobs are configured.

His solution was built entirely on the Clipper lib for offsetting. That was probably the best thing at the time but his solution didn't allow for newer offsetting libraries like Cavalier Contours. CC is blazingly fast but incorporating it into RT's PathArea is beyond my skill.

His solution didn't take into account what anyone else was working on in Path at the time. We had to adapt our stuff to his PR.

I don't mean to pick on either RT or his contribution in Path, it's just that it is the one I know. I accepted it (at Yorik's recommendation) and I still think that was the right call. His contribution was a step forward at the time but we paid a price to get it. So much of that pain could have been avoided with a little conversation.

[johnwang]

My point was that it is normal for one that is entering in a project to further develope code made but others, to have to make some efforts and to spend some time to grasp the logic. Time and difficulty will depend on the complexity of the software, on how well it is documented, on the possibility to ask for a clarification to previous developers

Per your earlier comment, you're not a software developer. A programmer, perhaps, Certainly a smart guy, but not a software developer.

A software developer's main job is to thoroughly understand the problem being addressed. That's more than just the problem at hand, it's also the context and nature of how that problem changes over time. A developer - a really good craftsman with experience - will create code that is more than a clever program. It's code that is:

Written to be maintained.
Has test cases
Conforms to generally accepted practices
Has good separation of concerns
Anticipates future features
Accommodates parallel work in other areas

When RT sent his contribution, it completely ignored all aspects of the current workflow. He may be a great programmer but he's no machinist and I doubt has ever worked in a CNC shop. His solution, while very effective at polygon offsetting ignored all kinds of realities about how CNC jobs are configured.

His solution was built entirely on the Clipper lib for offsetting. That was probably the best thing at the time but his solution didn't allow for newer offsetting libraries like Cavalier Contours. CC is blazingly fast but incorporating it into RT's PathArea is beyond my skill.

His solution didn't take into account what anyone else was working on in Path at the time. We had to adapt our stuff to his PR.

I don't mean to pick on either RT or his contribution in Path, it's just that it is the one I know. I accepted it (at Yorik's recommendation) and I still think that was the right call. His contribution was a step forward at the time but we paid a price to get it. So much of that pain could have been avoided with a little conversation.

So you didn't thoroughly understand his contribution and accepted it on other's recommendation? Confusing.
And after he presented his PR, have you tried to communicate with him? or he reject any conversation?

[johnwang]

I will still express my feelings that one of the early orders of business should involve creating something along the lines of a 'development committee'

Don't think this is FPA's business in general.

[wsteffe]

Per your earlier comment, you're not a software developer. A programmer, perhaps, Certainly a smart guy, but not a software developer.

What I wanted to say is exactly the opposite, but I may have said it badly, My fault. Actually I wanted to say that I am not very proficient in all the computer languages (C++, fortran, python..) that I am using to develop my software. But I think to understand very well the problem (in the numerical electromagnetics) that I want to solve. And I agree with you that this is more important (to have the job done) than being able to write a very elegant code or to exploite the full potential of a programming language.

I do not pretend to be an expert in many other technical areas and for sure I am not an expert of CNC machining. I am used to send mechanical designs to a shop which is providing a CNC service to me. I just know, more ore less, what I may ask (which kind of shapes and which accuracy) to them and what not. Because of that I do not want to speak about the specific technical problem addressed by RT PR for path. I assume that you know better than me the goals of your project and what is well suited (or not) to achieve these goals.

In the same way I trust RT, when he speaks about the TN problem, more than anyone else here in the FC community. This is because he has made a big effort to understand this problem and to find solution for it. He is also (at least in my opinion) proficient in C++ but, again this is not the main point. And I do not agree on the general idea (which is asserted by many in this community) that his work, to be approved, need a deep review from people like wmayer, yorik or anyone else who doesn't have such a deep knowledge of the TN problem.

It is not the duty of a project leader to enter into the details of all the different technical problems which have to be solved in a project. Nobody may be an expert in all disciplines and a good project manager is, in my opinion, somebody who accepts that somebody may be better than him (for a specific job) and gives trust to him.

The only point that you (sliptonic) made regarding RT matters to me is when you said that he is not collaborative. For sure it is difficult to work with a person refusing to collaborate or even to communicate. But a collaborative working environment requires a positive attitude from all the parts. You are claiming a misbehaviour from the RT side, but who may really know how the communication problem was born in that circumstance.

[johnwang]

It is not the duty of a project leader to enter into the details of all the different technical problems which have to be solved in a project.

It is a sign that the project leader can not cooperate.

[GeneFC]

This topic has completely lost its identity as an Announcement.

See https://forum.freecadweb.org/viewtopic.php?f=9&t=38145

Thread locked.

Gene