On the implementation of input and output nodes #37
Replies: 3 comments 3 replies
-
|
As a start, and for everyone's convenience, I'll quote the first design/proof of concept presented by @ambientdark333 and @sbudro here, since it was the first step/proposal regarding input/output in Nodezator graphs and currently the only one as far as I can remember.
I'll share my thoughts on such proposal as soon as possible, but it will probably take some days, since I need to divide my time among a lot of tasks regarding Nodezator and the Indie Python project. Y'all have a nice week 😉 |
Beta Was this translation helpful? Give feedback.
-
|
I added another input node for testing. This new input node is type dict and works very similar to the output node. This allows you to create a node that can accept a dict containing any type and/or quantity of values so you don't have to create specific inputs for different types beyond the string, int, float, and bool already presented. Under the hood this just creates a function parameter with the node name as the variable name with type dict and default value None. Within the node you can use get_at_string to access the value associated with any key in the dict you received. It would be nice to be able to loop through all of the keys/values in the input dict and/or check for a specific key in the dict without crashing the application if that key is not present but this would require another special node using dict.get or something similar unless I am missing another builtin method for this. I suspect that this will be easy to refine further once the branching is in place as well. Overall, I am not crazy about the generic dict input parameter for nodes because you cannot see what those nodes expect to get as keys/values in the dict without viewing the node source code but it does appear that using a dict for any number of inputs/outputs along with the expected type works well with the rest of the existing system. I thought about creating an input dict node that would allow you to specify keywords, types, and values for all inputs but I think that would require you to have more widgets for custom types such as DataFrames, Decimals, etc and would still limit what you can send to a node in some ways. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, everyone, I hope y'all are having a nice day. @ambientdark333 and @sbudro, sorry for the delay on my reply. For now, this reply takes into account the proposal @sbudro posted here, which I pasted as the first comment of this discussion. First of all, in no way a day or two or three will be enough to evaluate a proposal of this kind, because the feature to be implemented just happens to relate to a lot of different features and "services" within Nodezator. It will be something for which I'll have to schedule time to. In other words, there's just too much moving parts. But it's nothing to worry, really. It just means we'll have to push forward one step at a time. So, without further ado, here are my thoughts on your proposal so far: Your approach when thinking about a solution for an input node is very similar to how I do things myself. I try to find something that already offers functionality close to what I need and try to adapt it to my needs. However, in order for this to work, the solution presented must meet the purposes of the feature. In our case our purpose is to create input and output nodes that serve to define a signature for the function represented by our node graph, so that we can export the node graph directly as a full-fledged function, without having to tinker with the code afterwards and being able to use the exported code as the definition for a new node. With that in mind, here's a first question: (1) Nodes in Nodezator are highly versatile in that they can represent any kind of signature a given functions has. This includes positional-variable ( Now, I myself don't have an answer for that either. I'm just pointing out that the design and implementation of the input/output nodes feature is an endeavour larger than it seems at first. My preliminar thought is that though having simplicity as an advantage, your proposal for input nodes doesn't meet the needs/purpose of the feature. I actually think that Blender3D handles input/output of group nodes rather appropriately. Even so, several adjustments would be needed if such design would be brought into Nodezator. For instance, the aforementioned inclusion of variable parameters. Please, take a look at the video linked below. In the video you can see that when a node group is created in Blender there are 02 nodes, named "Group input" and "Group output", that control the input/output of the group: See how effortlessly it is possible to create new parameters just by dragging existing parameters from nodes inside the group into the input node? Additionally, the new input created in the group input node inherits the type/widget used, so the user doesn't even need to worry about it. Of course, if needed, in Blender the user also can create parameters independent of the ones in the inner nodes. Here's another question: (2) Can your proposal be extended to allow the definition of new parameters with the same ease as shown in the video, without the user needing to worry about the type/widget used? I think in the present state your proposal would make it very difficult to provide such functionality. Due to such complexity, I think it would be more appropriate for input nodes in Nodezator to be represented by a new class rather than using proxy nodes. There's just too much additional services it needs to provide in order to fulfill its purpose. For the same reasons, I also think the output node should be a class apart, rather than reuse a built-in node for dict, even though the output node will need far less new services than the input node, since it is quite straightforward. Actually, just like a single output node controls all the outputs of a graph, I think it would be better to have a single input node contain all the inputs as well, like the Group input node in Blender. This is due to various reasons, like organization in general and because it can better manage the inclusion of variable parameters. Please, let me know what you think of my feedback. As I said, I won't impose my design (something similar to what Blender3D does), but I need to make sure that, whichever design/proposal gets accepted in the end, it meets the requirements of the feature. For that to happen there are a lot of aspects and layers we'll have to analyze in order the ensure the final design chosen is adequate. I have yet more questions, but I think we should advance one step at a time. I think this feedback here is a good start. Considering what you've shown me, I think a design closer to how Blender3D handles stuff is still more adequate for Nodezator than the one you've shown. |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone! I appreciate the thoughtful discussion about this feature so far. Subgraphs are obviously an important and complex feature requiring a lot of thought. (I will refer to this feature as "Subgraphs", but it's known by many names in other apps: Groups/Gizmos in Nuke, Groups in Blender, Compound nodes in Maya, Subnets in Houdini. Feel free to suggest a different name.) Subgraphs in a node editor are like functions in a text-based programming language. Based on this analogy, I can think of a few design options/questions (none of which I have an answer to):
I'm sorry for the stream of consciousness! As I said, I have no answers at all, but I wanted to write down these topics so that we can all discuss them further. |
Beta Was this translation helpful? Give feedback.
-
Your stream of consciousness is extremely welcome and may help identify the best paths or principles to be considered. It is much appreciated. As always, I'll provide a more insightful reply in few days. As I mentioned before in this discussion, I too have some design ideas that I'd like to contribute as well and also make available for people to discuss. Stuff that I didn't have time to write and will probably only write about after finishing my work on the automated GUI tests and looping/branching. Unfortunately, it seems the initial efforts from the users that started contributing their solution found too many constraints, since we didn't hear from them in a long time, as evidenced by the amount of time elapsed since the last message in this discussion. It's OK, though. We can always pick up the work/discussion where it was left off. |
Beta Was this translation helpful? Give feedback.
-
|
As always, here's a proper reply to your questions/feedback/concerns. Thank you for taking the time to share them and for the patience to await my reply. No need to rush. Read my answers at your own pace, when you have time. Yes, this feature requires a lot of thinking, since the possibilities are many, which is why we need to approach each idea with patience and examine it carefully to ensure the final design is versatile and flexible enough to tackle the problems for which it is implemented. This is the kind of feature that mustn't be rushed no matter the circumnstance.
I concur. My idea is for subgraphs to work similarly to group nodes in Blender. Subgraphs represent functions just like you said. In fact, every .ndz already represents a function with no parameters and whose return value is None. This is exactly what you get when you export the graph to Python. Implementing subgraphs in Nodezator will probably start by allowing users to define parameters and a return value for their .ndz files. Defining parameters and a return value will probably be done via two special nodes, the input node and the output node, that will sit at the left and right corners of the graph, respectively, just like it is done in Blender. After the user is able to define parameters and a return value, then we'll just have to make it so an .ndz file can be loaded inside another .ndz file opened in the app. Also, the possibility of importing a subgraph by first converting it into Python code then loading it into Nodezator is something I was thinking of doing at the beginning but I'm not satisfied with this solution anymore because converting a .ndz file to Python causes 2D positioning data to be lost. That is, the Python script only has the functions calls, not data about the position of the nodes such calls represent. Once we loaded the equivalent Python function into another .ndz graph and had to navigate the subgraph internally, we'd have to guess the position of the nodes representing the functions calls in the Python file. In other words, this solution is unfit and it is indeed better to export the subgraph from its original .ndz file directly. Another feature of group nodes in Blender is that, if I recall correctly, group nodes can be either linked or imported from another .blend file. At first I was intending to just allow a subgraph to be copied into the .ndz file importing it, so that it would not be an external dependency anymore. That is, I was thinking of only allowing subgraphs to be imported, but not linked. However, I believe allowing external subgraphs to be linked as well is useful just like we import statements are useful in programming languages. That is, it would be problematic and sometimes impossible to copy everything that we want to use into the .ndz file. Thus, just like in text-based programming we import functions rather than copying them into the scripts, we Nodezator I also want subgraphs to be linked. So we have two ways of accessing an external subgraph: by importing or by linking. Both importing and linking will make the subgraph appear in the canvas as a node. The title of the node will be the name of the .ndz file (we already do something similar when we export a .ndz file to Python, we use the name of the file as the name of the function). It will also have an id at the bottom, just like regular nodes. When a subgraph is imported, it would be copied into the .ndz file and we'll be able to access, browse and edit the subgraph as if we had just opened the .ndz file into the app. It will be just like opening a folder in a file manager app: the same way clicking a folder causes the contents of the current location to disappear and the contents of the folder we clicked to be displayed, we'll be able to "enter" the subgraph, inspect or edit it, then exit it to see our own graph one level above. This means an .ndz file will be able to have nested subgraphs. In other words, imported subgraphs will be just like folders holding more nodes. When a subgraph is linked though, we would only be allowed to see and use the node in our graph, but not edit it there. Trying to edit it would probably open a dialogue offering to open the original .ndz file of the subgraph so we edit the original file itself. Both imported and linked subgraphs would have dedicated icons indicating what kind they are, so we can spot immediately when a node represents a subgraph and whether that node links data from outside or it is part of our graph now and thus we can edit in our own .ndz file. You also said...
I also agree, that's precisely what subgraphs are. Just like we define the
As I said before, the user can create any .ndz file, edit its parameters and return value, then the subgraph can be imported or linked inside another .ndz file at will. However, what you said is also possible and looks like a convenient thing to add. That is, to allow the user to create a subgraph node inside the .ndz file. The subgraph would be created just like an empty .ndz file, with no parameters and returning None. Then, the user would just have to "enter" it, add nodes, edit its parameters and return value, then exit, and the subgraph node would be ready for usage. Additionally, there could be an alternative option to replace the subgraph by its inner nodes, that is, to remove the subgraph node and leave its inner nodes in its place, showing them directly in the graph. This could be useful when we have a subgraph that is simple enough and we don't want to be entering/exiting the subgraph every time we want to edit the subgraph.
Since we'll be able to import/link .ndz files inside other .ndz files, that is, to nest them, they can get as complex as we want. In fact, if you think about it, in the perspective of the design I mentioned every .ndz file is already a subgraph. How all of this will interact with the node packs and its inner levels (categories, script folders)? I've been thinking about this for a couple of years, well before releasing Nodezator last June (2022). After that much thinking I believe I'm closer to a satisfactory solution, but both the solution and the problem per se still need to be given more thought. I'm thinking of including the subgraphs (as .ndz files) in the node packs themselves. Since they are just .ndz files, they could be put both inside a category folder, so they would be part of that category as well, sitting beside the node script folders, and inside the node pack folder itself, to indicate they are more general group nodes that use regular nodes from multiple categories. I think the solution is simple and straightforward, but still not complete. There's more to discuss about this solution (and the problem it attempts to tackle). Let's examine it a bit further, but first let me say this: What I'll explain about it in the following paragraphs is not in defense of nor against the presented solution. It is just stuff I'm thinking about before making a decision (also, even after I achieve a satisfactory understanding of all this, I'll still make it available for discussion before any final decision is made, just like I've been doing for looping/branching). Let's get back to the discussion. Here's a curiosity about the solution: on the conceptual level, don't you think subgraphs, just like the .ndz files that they are, represent data rather than code? That is, a .ndz file is just data (in the form of a literal Python dictionary) that tell us how to combine calls and it provides some more values for the arguments. In that sense, group nodes are just more data as well. They are just data in the .ndz format that we are nesting in our own .ndz file loaded in the app. The actual code is the source of each node, but the .ndz files, and hence the subgraphs, are just data. However, there's nothing inherently wrong with this. Even if the group nodes/subgraphs are just data, we may still think they represent operations that are important enough that we want to include them along with the other nodes in our node pack. It is actually fine. Even, so, a purist might say:
And, to be honest, it would not be wrong. I myself am no purist, so I still think it is fine to include data in the form of group nodes/subgraphs in the node pack if the data is useful. Let's explore more. This time, let's for a second assume subgraphs are code, even if indirectly. After all, they do represent behaviour, even if they just describe how to combine different existing behaviours (the regular nodes in the node pack). However, even in this perspective of group nodes/subgraphs being code, don't you think they look a lot more like "application code" rather than "library code"? According to wikipedia...
In other words, regular nodes look a lot more like library code and group nodes/subgraphs resemble application code. So, again, a purist might say
Again, I'm no purist, I still think that it is more than ok, and actually desirable and useful, for a node pack to include group nodes in it. After all, some node groups may represent operations that are so commonplace that not including them would make our node pack feel incomplete, even though the users could create that group node on their own using the regular nodes provided. Isn't this what Python does when it advertises itself as being "batteries included"? There's a lot of extra stuff in Python's standard library that is not needed, stuff that the users could (easily, in some cases) come up by themselves, and yet their presence does not harm the experience. Quite the contrary: in my honest opinion people will often find themselves taking advantage of the more obscure/specialized standard library modules that they initially thought they'd never need. Let's keep exploring. Remember, we are just trying to learn a bit more about the solution I proposed and its implications. Nothing is set in stone. Going back to the speech of the purist I just simulated a few paragraphs ago, we can notice yet another interesting remark: "Let's however allow people to produce and distribute their own group nodes/subgraphs...". This begs the question: how will people distribute their own subgraphs to begin with? I mean, they are just data, right, not python code, so they'll not use pip/PyPI right? Suppose we used a workaround and could do that, would it still be desirable? Wouldn't it be overkill, being able to publish and install node packs containing only subgraphs from PyPI? Even if we do not use PyPI, a way to publish node packs containing only group nodes/subgraphs may indeed be desirable. Why? The reason is simple: a .ndz file can load nodes from multiple node packs. Even though I think it is okay to provide subgraphs inside the node pack, this will not be enough, because .ndz files (and thus subgraphs) can reference nodes from different node packs. So, even though I don't agree with the imaginary purist I've been simulating, his opinion that subgraphs must be kept separate has some appeal. Not enough to convince me, though, but enough to leave me puzzled/intrigued. To be more precise, I like my solution of keeping the group nodes/subgraphs inside the node pack (either in the top level or inside a category folder), but for a solution to be complete, to take advantage of the full potential of subgraphs/group nodes, we must also think of a way for people to share their own subgraphs by themselves, without any Python code involved, probably using the same structure of node packs, but only with .ndz files. This way, such node packs would be able to hold group nodes/subgraphs that use nodes from multiple node packs. Let's go deep into why having subgraphs with nodes from multiple node packs is desirable and useful. In summary, even though 02 isolated node packs may have nodes created for different purposes, there may be synergy between the nodes in the different node packs. For instance, let's imagine 02 node packs created in isolation. One generates 2d positions and the other generates 2d art. They might be compatible to be used together to produce simple 2D animations. As another example, a node pack used for generating 3D geometry may be useful in conjunction with another node pack that specializes in rendering with several different algorithms. And so on. All of this and we didn't even begin to discuss recursion yet (skull emoji) But that's ok. I think what I shared here summarizes my ideas/concerns/challenges regarding distributing/sharing subgraphs. Fortunately, we still have a lot of time to mature those ideas, since the list of things to implement is still long and I won't be implementing this feature so soon. Also, even when it is time to implement it, I'll first write a first draft of the feature to present and open the topic for discussion (again, just like I did for the looping/branching feature). This is, after all, a feature that we must not rush at all costs. As a curiosity: As I was discussing the differences between code, it might be tempting to think that I think of data as though it doesn't have quite the same status as code. However, I was just concerned with a way to share it on PyPI, not with the fact that .ndz files are data. On the contrary, the fact that code can be described in a data format attests to the modularity (and why not quality) of such code. Languages like Lisp and its variants even treat code and data interchangeably and in the case of group nodes/subgraphs it seems the thought is compatible.
Yes, I want to allow it. I want all and every paradigm/approach available in Nodezator, so long as I can come up with a design that is simple enough. I still didn't think about how it'd be done though, so unfortunately I don't have anything to share in this respect. Yet. I already began to think about it but I still only have speculations, no concrete behaviour or design to share. Moreover, some aspects of the solutions/proposals/concerns I've been presenting to you can only be accurately assessed in practice, that is, once we have the opportunity to try them. Even stuff for which I wrote a complete design like branching/looping might in the end prove unsatisfactory and require changes in the original drat. This is why I give my ideas draft status, rather than calling them proposals. I'm saying this because I think recursion is one of such features which are better understood/designed as they are implemented. Even so, I'll still try to come up with a first design when it is time to implement subgraphs, specially since there's so many aspects of subgraphs to consider (as seen in my comments in the previous question) and thus leaving something for last will likely hurt the design, even more if it is something challenging like recursion (despite the simplicity of the concept).
I'll reply based on what I understood from your question. Please, if I missed your point somehow or forgot to clarify something, don't hesitate to provide further explanation/context so I can properly address your question/concerns. I'll actually make my reply to this as comprehensive as possible, so it increases the chances of it addressing your question. So, by user-defined types do you mean custom widgets defined by the user? I agree. However, before doing that a few steps must be taken:
I think it is important to allow users to define their own custom widgets because when it comes to widgets the possibilities are virtually infinite, which is why GUI libraries allow custom widgets to be defined, in my honest opinion. This'll all take some time. However, I think I should have already listed this in the list of planned/request features, so that users know I'm aware of it. I'll set some time aside to do so. I'm talking about widgets, because, strictly speaking, as stated in the manual, Nodezator actually doesn't put any restriction on the input/output types. That is, people can already use whatever they want as the annotation of their parameters. No type is checked or enforced. In fact, in Nodezator, annotations are just a convenient hint to indicate what object is expected in an output (or out of an output). Based on that information, the node uses a custom color on the socket to indicate a particular type and chooses a suitable widget for the kind of values expected in that parameter if one such widget is available. For instance, when you are instantiating a data node (right-click canvas, then click "New data node"), you can pick a widget based on a type (string, integer, etc.), but the types are only listed to help find a suitable widget for them. You can even click in the "More options..." command that appears in the same popup menu and a form with other useful widgets are presented, like the color button. Just as you said, I want people to have all the freedom they want to define and use their own types. Put it another way, why even have operator nodes with they were only meant to be used with numbers? The int/float entry widget already can perform arithmetic operations, so in theory operator nodes like '+', '-', etc., would not even be needed. However, they are there so that they can be used with other types as well, including types made by the users, so that they can take advantage of operator overloading. For instance, the user can create a custom image type that interprets '+' as using the "add" blending mode when adding two images of that custom type together. Besides a lack of a custom widget defining API/plugin system, the only other restriction I can think of right now is that, even though the user can define its own types, the raw data in the widgets is stored/serialized as a Python literal (that is, a built-in type). Could that perhaps be your concern? If it is, then, that is indeed a restriction and something made on purpose. Whereas the custom widget thing is a temporary restriction until I have time to design a better system, the serialization of the data as a Python built-in is not meant to be temporary. However, at the same time, is not something about which I'm adamant. Let me explain: It is just that I think Python built-ins are actually satisfactory for this. Python itself does this as well. For instance, there's no custom way to represent a Decimal in Python, so you must encode decimals in your code as strings and pass them to decimal.Decimal in order to use them. In the same way, if users have custom types that they want to use in their graphs, they need to be able to serialize the raw data as a Python built-in and instantiate the actual object in the graph itself. I'll continue on this train of thought just for completeness, even though this might not be the actual concern you are trying to convey. For instance, the user could create a node like this (remember any callable can be a node, even a class): class Grid:
def __init__(self, grid_data: list):
...
def __add__(self, another_grid: Grid):
...
...
main_callable = GridThe Here's what the widget could look like.
The widget here would be defined by the user, and it stores the data in the .ndz file as a list. Clicking in the pencil (edit button) would open a custom panel so the value could be edited. The panel could even go as crazy as needed, even allowing the user to load data from a file. The color button widget can do this. When you click in the color editor button in the widget a panel/window consisting of the color editor opens, and it offers multiple ways by which to pick one or more colors: by their html names, by their rgb values, using red, green, blue values, using hue, lightness, saturation, value, with sliders and by looking for a file with a specific format. You can also export the color to a custom formatted file so you can use the colors later in other projects (this custom formatted file is the one that can be loaded back). This color editor isn't even ready yet, there's still extra options that I want to implement. So it is perfectly fine to use However, let's assume you'd like to store grid data even more complex than what Python built-ins seem to be able to offer. You can still use a custom binary format and encode it as a bytes object, which is also a Python built-in and can be stored in the .ndz file. As long as the API/Plugin system is expressive enough, the user should be able to define custom widgets and extra panels/windows used to edit the data and serialize it back as a Python built-in. I'm not denying thought that there are many other formats more useful and desirable than a Python built-in. However, for those cases, you can still just use the format you want anyway in an external file and only reference the path to the data file in the .ndz file. We also do this in Nodezator. For instance, we do not store images in the .ndz file, because this data is best kept in .jpg or .png files where it can easily be edited in image editing apps. Instead, image data is referenced from outside the file, using strings representing the path pointing to the image files. We do this by using a special preview widget, that though only stores the path to the image file, is able to read the file and present a preview of it in form of a thumbnail. Nodezator has many widgets that work like this. A general one that just shows the path(s) stored and other ones that in addition to store the path(s), also offer thumbnails previewing the content, like the audio preview widget, text preview widget, video preview widget and the image preview widget we just mentioned. In the case of the Grid node we presented in the past image, another version of it could be made just like we mentioned above, using a preview widget that only stores the path to the grid data (that could be JSON or any kind of textual or binary data the user wants). Again, that widget would be provided by the user so it behaved just like the user wanted. The only different between widgets that hold data themselves and widgets that reference external data (paths) is that widgets that reference external data don't have extra panels/windows to edit the data. Since the data is kept outside the .ndz file anyway, we assume the user can just use another more suited and specialized app to edit that kind of data. Here's what the script and resulting node could look like, using a "grid preview widget": class Grid:
def __init__(self, grid_filepath: str):
...
def __add__(self, another_grid: Grid):
...
...
main_callable = Grid
Could those things be what you are concerned with? Let me know if they are not, or if they are but you are still not satisfied with my explanation, and please provide more context/examples so we can discuss further. If the entire reply to this question missed your point somehow, please, let me know.
No problem. Quite the contrary, all the feedback/concerns/constructive criticism are what makes Nodezator and the Indie Python project open-source projects. Taking time to reply questions and feedback is not a mere convenience to the members of the community: it is an integral part of the project and what guarantees that the project will evolve as healthy and powerful as possible by taking into account all opinions. Ask/share as much as you want, regardless of whether your ideas are complete or not, whether they are just concerns or not. Additionally, as you may have noticed, this is all very interesting and fun to me, otherwise I wouldn't be doing this. Just have in mind that I might postpone replying sometimes for a few extra days, in order to give attention to the current development tasks of the project. Even so I'll reply to all questions/feedback eventually, so just keep'em coming in your own pace. After all, I reiterate: answering the users and the exchange of ideas is an integral part of an open-source project, as important as the development work itself, if not more, because they help ensure that the development work took all possible paths into account and the best one is being implemented. Here in the Indie Python project (and its subprojects like Nodezator) the outcome is very important, which is why we have drafts, lists of things to do, people have access to the most recent local commits and I'm always updating users on discord and Github discussions regarding the progress of the current development work. However, by this point you must have already noticed as well that the process is as important as the outcome, which is why I value the discussions, sharing of ideas/feedback, looking into recommendations of online materials/resources. In other words, without loosing sight of our destination, we must also enjoy the journey, that is, the discussions, learning experiences and also the challenges which are many. Peace |
Beta Was this translation helpful? Give feedback.
-
Concept: Input and output in Nodezator
Hello, everyone,
The idea of inputs/outputs in Nodezator was first suggested/commented by asgore in this highlighted youtube comment where he asks "can we create new functions in the editor using nodes?".
Several months, later @ambientdark333 and @sbudro have been exchanging comments with me, starting with this one, where they presented their design and implementation of input/output nodes as a way to define inputs/outputs for Nodezator graphs. As ambientdark333 mentioned in one of his messages, being able to define inputs and outputs inside Nodezator will help us not only to export the .ndz files as functions with defined signatures but would also allow said functions to be used as nested graphs within other .ndz files, just like macros in Blueprint (or as I mentioned, like group nodes in Blender).
This discussion
This discussions aims to gather suggestions/feedback/ideas/requirements regarding the introduction of input and output nodes in Nodezator. Here anyone can
I also plan to share my own ideas, but in no way I want my word to be taken as final on any matter. Even though I'm the source maintainer of Nodezator (and the Indie Python project in general), I want my role to be that of someone participating in the process and at most helping mediate the discussion as needed.
Only in the extreme case where consensus cannot be achieved or I find some design inherently flawed, potentially harmful or just plain unnecessary, I am to give the final word or exercise my veto power, always explaining the reason behind it.
I won't define a specific date for this discussion to finish yet, since there's still much to discuss and decide (and I have a lot on my plate with the implementation of branching and looping to begin on December 10th.
Beta Was this translation helpful? Give feedback.
All reactions