specification
specification copied to clipboard
serverlessworkflow
Define a "Priority of Constituencies"
The Web Platform Design Principles are the guidelines for designing web & browser apis. They define their "Priority of Constituencies"
If a trade-off needs to be made, always put user needs above all.
Similarly, when beginning to design an API, be sure to understand and document the user need that the API aims to address.
The internet is for end users: any change made to the web platform has the potential to affect vast numbers of people, and may have a profound impact on any person’s life. [RFC8890]
User needs come before the needs of web page authors, which come before the needs of user agent implementors, which come before the needs of specification writers, which come before theoretical purity.
Like all principles, this isn’t absolute. Ease of authoring affects how content reaches users. User agents have to prioritize finite engineering resources, which affects how features reach authors. Specification writers also have finite resources, and theoretical concerns reflect underlying needs of all of these groups.
And since this spec also has to balance the needs of "writers", "operators" and "implementors" I thought it could be valuable to define similar guiding principles to help us make decisions.
Obviously we do no have to go with their wording (or even their order, even though I agree with it). A good place for it could be in the or next to the Design section of the dsl.
I love the idea! It's IMO exactly what the DSL should be about: user before all.
@ricardozanini @JBBianchi @fjtirado can we proceed with it? If so, @matthias-pichler-warrify can you open the related PR?
Sounds good 👍 do we have consensus on which personas to include, the naming and the definition?
Are we ok with:
authors: people authoring workflows (or should we go withusers?)operators: people running and operating an implementation of the spec (or should we leave these out?)implementors: people implementing a spec compliant runtimespecifications writers: people working on the specifications of Serverless workflow
Do we want to take the web platform wording verbatim, or change anything? (Bedsides the naming)
Love your naming suggestions, so +1 on those!
Do we want to take the web platform wording verbatim, or change anything?
At this point in time, I personally don't see any reason why not to take it verbatim, aside from the only think that's actually tickling me, which is about theoretical/lexical/semantic purity coming last, which imo can lead to people pushing for brievety at the cost of clarity or fluency.