Replies: 9 comments 16 replies
-
First three points seems fine (maybe number them so discussion becomes easier). About tests though; should PRs be rejected if they don't have "lots of tests"? I think every PR should have a least one test to show what it solves, but what is "lots"? I'm open for flexibility.
Can you clarify what you mean by this?
And also this. |
Beta Was this translation helpful? Give feedback.
-
With respect to the modelling context, I would expect that it either stores enough information to regenerate the model at any state or stores the model at all states (classic trade-off between time and space). With such a context, one would be able to introduce new operations like "find the edges produced by operation x". What would the scope of such a context be: a Solid, a Compound, an Assembly? Would models/contexts be able to be combined - say create model one which would have its own context; then create model two with a separate context; then combine the two models - how many context are there now? 2 or 3? |
Beta Was this translation helpful? Give feedback.
-
With respect to PEP8/PEP484 and snake_case method names, it would be easy enough to add snake_case aliases to all of the existing camelCase names. At some future date the camelCase names could be removed. |
Beta Was this translation helpful? Give feedback.
-
Ok, for clarity, I believe i've incorporated the suggestions so far in the wiki page |
Beta Was this translation helpful? Give feedback.
-
@dcowden I really love what you're doing here in terms of scoping out a roadmap for the future. I've been a CQ user since around 2017, and its an invaluable tool. So far, I am in agreement with principles and goals outlined and I'm glad that there is a sensitivity to not make breaking changes--at least not right away! In particular the PEP8 method naming which is potentially a breaking change without aliasing. I'm not sure I can contribute anything meaningful other moral support but I shall look forward to following this story as it unfolds. |
Beta Was this translation helpful? Give feedback.
-
thanks @michaelgale for the words of encouragement! I'm very excited about several new features we have been talking a lot about:
|
Beta Was this translation helpful? Give feedback.
-
I understand that this is not the first priority, but I wanted to comment on the release schedule. It has been a long time since the last release and there are a lot of new features that are important and powerful in the current main (such as the combine argument in the eachpoint method). I believe not having more frequent releases is making it harder for new users and limits the growth of the CQ userbase. I believe that this point is support by ROE 5 -- to keep things moving forward. Regarding consistency in the codebase, I agree with prior proposals about moving entirely to snake_case and keeping linked copies of methods to avoid breaking changes until a later release. I also feel strongly that the input data types should be made consistent, and this is a particular problem for moving/translation methods (tuple, cq.Vector, cq.Location(cq.Vector()), etc). |
Beta Was this translation helpful? Give feedback.
-
I'll scope my comments to only the section referenced in the title.
Can we say this with any certainty? We've never done a survey of our community.
Agreed, and not just in consistency of how snake_case vs camelCase is used, but logically consistent as well so that if a user learns a concept that applies to one operation, they can expect that it would apply to a different, similar operation as well. There have been discussions about how CadQuery acts differently in some places that should act the same.
This is very broad and open to interpretation. What is the success condition of this? What does "small and self contained" mean? Doesn't this have to scale to the situation as well? I think that if you are wanting to contribute code that fundamentally effects how CQ operates, it's reasonable for the core devs to expect that you have familiarized yourself with all the related code, even if there is quite a bit of it. The inverse of that is that it's not reasonable (in most cases) to expect someone contributing documentation updates to understand the underlying code.
Is this supposed to be nested under item 4? Also, is it supposed to read something like "As a volunteer project we understand people have limited time, but we want to keep moving forward." |
Beta Was this translation helpful? Give feedback.
-
With no more comments, I think we have documented consensus |
Beta Was this translation helpful? Give feedback.
-
1. Rules of Engagement/Philosophy
The first step of roadmap discussions is to set the rules for roadmap discussions!
The proposed rules of engagement are at https://github.com/CadQuery/cadquery/wiki/RoadMap#rules-of-engagementphilosophy.
The goal of this discussion is to reach consensus on these rules, before moving on to our objectives
Beta Was this translation helpful? Give feedback.
All reactions