You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently it was mentioned that the Epiverse-TRACE blueprints are more focused on process than on design. For a lot of the discussions we've had around design have referred back to the Tidyverse design guide.
Is it worth adding a chapter (or just a few sentences) to blueprints, similar to the Code review chapter, that states we work in accordance with the design principles laid out by the Tidyverse and then mention any differences? Or perhaps design is outside the scope of blueprints.
Would be good to hear people's thoughts on this.
The text was updated successfully, but these errors were encountered:
I agree - and I think we could go a bit further and add some design principles as well. My understanding is that we do espouse principles such as small self-contained packages, shared classes and general interoperability, modular package organisation, or user-friendliness. Speaking for {epidemics}, I think composability and modularity are fairly central with user-friendliness as the motivating goal. Perhaps these are more related to process, but they seem like design principles to me.
Recently it was mentioned that the Epiverse-TRACE blueprints are more focused on process than on design. For a lot of the discussions we've had around design have referred back to the Tidyverse design guide.
Is it worth adding a chapter (or just a few sentences) to blueprints, similar to the Code review chapter, that states we work in accordance with the design principles laid out by the Tidyverse and then mention any differences? Or perhaps design is outside the scope of blueprints.
Would be good to hear people's thoughts on this.
The text was updated successfully, but these errors were encountered: