Skip to content

Define a "Priority of Constituencies" #906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
matthias-pichler opened this issue Jun 27, 2024 · 5 comments · Fixed by #948
Closed

Define a "Priority of Constituencies" #906

matthias-pichler opened this issue Jun 27, 2024 · 5 comments · Fixed by #948
Labels
area: governance Changes in the Governance change: documentation Improvements or additions to documentation. It won't impact a version change.
Milestone

Comments

@matthias-pichler
Copy link
Collaborator

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.

@cdavernas
Copy link
Member

cdavernas commented Jun 27, 2024

I love the idea! It's IMO exactly what the DSL should be about: user before all.

@cdavernas cdavernas added change: documentation Improvements or additions to documentation. It won't impact a version change. area: governance Changes in the Governance labels Jun 30, 2024
@cdavernas cdavernas added this to the v1.0.0-alpha3 milestone Jun 30, 2024
@cdavernas
Copy link
Member

@ricardozanini @JBBianchi @fjtirado can we proceed with it?
If so, @matthias-pichler-warrify can you open the related PR?

@fjtirado
Copy link
Collaborator

We were already doing that, isnt i? ;)
Please go ahead

@matthias-pichler
Copy link
Collaborator Author

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 with users?)
  • operators: people running and operating an implementation of the spec (or should we leave these out?)
  • implementors: people implementing a spec compliant runtime
  • specifications 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)

@cdavernas
Copy link
Member

cdavernas commented Jul 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: governance Changes in the Governance change: documentation Improvements or additions to documentation. It won't impact a version change.
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants