Skip to content
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

Charter per Issue #261 #262

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

jasonsmithio
Copy link

First pass of a charter per issue #261

@jasonsmithio
Copy link
Author

signed work

Signed-off-by: Jason "Jay" Smith <[email protected]>
@duglin
Copy link
Collaborator

duglin commented Jun 19, 2024

@jasonsmithio I'm wondering if it's worth a separate "charter" doc when it says the same thing as the main README. Would it make more sense to just edit the README to make it clear that the top section is basically our "charter" or "goals"? Then the following section (non-goals) would flow nicely from that.

We probably need to clean-up some stuff in there anyway - like add xRegistry to the list of projects.

@jasonsmithio
Copy link
Author

This is just meant to be a starter but I am happy to update it with more details.

I do have a few questions thought. Is everything in the Serverless Landscape under our purview or just CloudEvents, Serverless Workflow and xRegistry? I also think there may be value in adding a simple glossary in the charter to describe key words such as "eventing" and such.

I am going to us some of the other WG charters for more ideas.

@duglin
Copy link
Collaborator

duglin commented Jun 20, 2024

We're definitely not just CE, Workflow and xReg, qnd we basically decide for ourselves what our next project will be. The problem is that a lot of the terms used (even "serverless" itself) is vague enough that it could mean anything. E.g. CloudEvents isn't serverless specific. Net: we're kind of winging it. :-)

re: glossary... maybe. I think the serverless whitepaper already has some of those - but be prepared for rathole discussions. However, it would help me if we knew what the pain point is that we're trying to address with this PR. I don't disagree that some stuff is stale and could use some clean-up, but I doubt there's much of a desire to spend too much time working on new docs "just because". That's why I'd prefer smaller, targeted, PRs that update the current text so it doesn't look old/stale rather than creation of new content unless there's a concrete need to do so.

As an example... in general the idea of a "charter" is fine, but when its content is already there in the README, the effort to convert it into a document as formal as a "charter" implies a lot of work and thinking because of the seriousness of the term. Combine that with the fact that we've gone years w/o a "charter" w/o any complaints or issues, it kind of brings up the question of "why now?" or "who really cares or needs it?"

As you might have figure out, I'm not a fan of bureaucracy - but that's just me

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants