We have a first idea but I guess we’ll have to improve it. This is what I have in mind right now, @luisherranz may have more things in mind. I’ll try to document this in other place once it’s clearer. Any feedback is welcomed:
Before the dev design, there is a process where we have to discover what the users need and define the user stories. This first part is a previous work to develop the feature.
- For example, if users ask for the comments package, we’ll investigate and talk with them until we know that they may need to be able to order them by newer/older, select how many comments to show, etc.
Once we know the goal of the feature and what functionalities are needed, we have to translate that into a technical solution. If there is a lot of uncertainty, the technical solution is not clear, and we think we are going to struggle to divide it in issues/tasks and estimate it, we should start a design phase to solve most of the questions.
- For example Support for Middleware in Frontity Connect may need design but the comments package not, because although we haven’t come up to a solution yet, it shouldn’t be difficult to estimate and divide it once we know what users need.
If we decide a feature needs design, one person will be responsible of it, but there’ll be a discussion here to discuss about it. The responsible person would analyze it, prepare some questions that need to be answered and suggest some possible solutions and the different reasons. From there, everyone can give feedback until we reach a solution where we feel comfortable. Once the design is done, we will open a time-box for RFC.
- For example, it could be something similar to what you did with Emotion and Styled Components.