Initial SIP process proposal

[aaronsteers]

I've incorporated all feedback and this is ready for final review. If no significant changes are requested, we can open voting as described herein!

Addresses #12

• Rendered SIP proposal draft: https://github.com/MeltanoLabs/Singer-Working-Group/blob/12-proposal-process/proposals/PR21%20-%20Proposal%20Documentation%20and%20Review.md
• Rendered SIP template: https://github.com/MeltanoLabs/Singer-Working-Group/blob/12-proposal-process/proposals/template.md

[visch]

Looks good to me, great start, should be able to iterate on this as we move forward!

[pnadolny13]

@aaronsteers the one things that not totally clear to me from reading the proposal is how the votes are conducted. Is the expectation that voting will happen during the live working group meetings?

I feel like we should probably allow for async voting too. Maybe we mention all voters in the PR a week prior to the upcoming meeting so that everyone has a chance to vote async and explain their reasoning, or not vote at all but at least they have a chance. I'm concerned for the case where theres a limited turnout for a meeting for whatever reason and were voting on a major proposal. In addition to or as an alternative we could also do a minimum vote count for a proposal to go through which could solve the issue too.

What do you think?

[aaronsteers]

@pnadolny13 re:

...the one things that not totally clear to me from reading the proposal is how the votes are conducted. Is the expectation that voting will happen during the live working group meetings?

I feel like we should probably allow for async voting too. Maybe we mention all voters in the PR a week prior to the upcoming meeting so that everyone has a chance to vote async and explain their reasoning, or not vote at all but at least they have a chance.

I like this idea a lot! I would certainly be open to async voting and ratification. The ideas I've had so far would be (1) votes in the text of PR comments, (2) emoticons on the PR, (3) Slack emoticons in our private channel.

To encourage candor and reduce noise of other community members potentially adding their own comments which could get jumbled with the votes, I increasingly feel like the most efficient approach would be to run the vote in Slack and then later pass on the results back to the PR once the vote has closed.

What do you think?

In addition to or as an alternative we could also do a minimum vote count for a proposal to go through which could solve the issue too.

Agreed on the need for some minimum "quorum" of voters in order to ratify. 👍 I don't know what the right minimum should be but likewise with the above, I'm happy to work this back into the proposal text.

[pnadolny13]

@aaronsteers

The ideas I've had so far would be (1) votes in the text of PR comments, (2) emoticons on the PR, (3) Slack emoticons in our private channel.

To encourage candor and reduce noise of other community members potentially adding their own comments which could get jumbled with the votes, I increasingly feel like the most efficient approach would be to run the vote in Slack and then later pass on the results back to the PR once the vote has closed.

Thats a good point it could get hard to track if other community members are commenting too. I like the slack idea for a final vote. Maybe we notify everyone a week beforehand by slack and by posting in the issue that the proposal is under review and voting has started, including the "vote by x" date. They can write issue comments with thoughts and discussion but they cast their final vote in slack, then when voting closes the tally gets posted to the issue.

Agreed on the need for some minimum "quorum" of voters in order to ratify. 👍 I don't know what the right minimum should be but likewise with the above, I'm happy to work this back into the proposal text.

My first thought is that we have our official list of representatives (idk if this exists or not) and we just need quorum (more than half) in both respects:

• a quorum of voters to cast a vote
• of that quorum who casted votes, a quorum of "accept" votes for it to pass

What do you think about that?

[dmosorast]

Happy New Year! Getting back into this. I want to give a +1 to all of the above. I've included a bit of that in my comments, some are requested changes (just wording related) while others are proposals of spelling more things out.

Feels like there's a balance we need to strike here between being too prescriptive and being too loose. We'll learn how best to do this overtime so it may be good to keep it more open, but setting up for a consistent and clean Singer-Working-Group primary repo seems like it'd be beneficial at this stage.

[dmosorast]

This question should be more direct like the other questions, i.e., "What are the downsides to this change?" to go along with "Which layer(s)...", "Is the change..", "How are Singer developers...", etc.

[aaronsteers]

@dmosorast - Thanks for this. I've updated the prompt to be more direct.

[aaronsteers]

@dmosorast - Re:

Feels like there's a balance we need to strike here between being too prescriptive and being too loose. We'll learn how best to do this overtime so it may be good to keep it more open...

I agree. And I've added a section to allow small edits/tweaks to incorporate our learnings over time via simple PR approval (along with a required changelog per doc) rather than requiring a full new process. While we certainly would want this "Edit" process to be used to slip in huge alterations, I think at least some flexibility is important to give us more confidence we can continue to to iterate based on learnings.

[dmosorast]

Might be good to have examples for each step just to align on formatting in the text here? Like do we want a specific prefix to scan issues for proposals more easily? Should we follow a hyphenated pattern for the rest of the branch? Underscores? Etc.

Open Issue of the format: Proposal: Add Widget to Singer
Create branch example: 14-add-widget-to-singer

[dmosorast]

Also, should this talk about working from a forked version of the repo to submit a PR? Should we add branch protections rules to this repo to require N reviewers for merge, etc?

This may be more operational concerns we can work out outside the scope of this, but curious if there should be any sort of guidance to keep the practice organized and keep this repo a bit clean.

[aaronsteers]

@dmosorast - Thanks for this. I've added example file names and branch names, just be very explicit, per your suggestion. I've also added guidance that creating on the main repo and on a fork are both completely okay.

[dmosorast]

It seems to me that this would be better written more directly for the responsibilities of the author to keep the review moving forward. Something like:

If changes to the text of the proposal are needed as a result of the review process, the author(s) must update the relevant proposal text to address this feedback to continue moving forward in the review process. Author(s) must also update...

This might feel a bit more formal than a standard PR review process, but it is more formal, trying to align everyone. It kind of also brings to mind the question of adoption of an orphaned proposal or adding authors, etc. That could be left alone for now though, I think. Just a curious thought.

[aaronsteers]

@dmosorast - Agreed! I've updated the wording to be more clear, per your suggestion.

[dmosorast]

I like the discussion here about a quorum and referring to Slack voting (or just maybe mentioning a generic poll to not be too tool dependent in the text) and timespan that a voting poll will be open. Feels like that should be included here as part of the practices.

[aaronsteers]

@dmosorast - Per our meeting last month, I've added a lot more clarification now on how this will work.

[dmosorast]

Thinking about this. I think the git repo is a good way to allow for individual evolution over time of concepts (since everything's recorded with a history), but for making these changes, seems like that should be another process (maybe another SIP so as to not bulk this one up too much. If the group determines that would be good to have.)

[aaronsteers]

@dmosorast - Thanks for these thoughts. I've added a section about "Lifecycle Edits" - which intended to cover small clarifications/updates being okay by simple PR approval, with examples of what significant updates would and would not be appropriate for that process.

Hopefully this sets at least a framework for small iterations/improvements that's not overly cumbersome.

[aaronsteers]

From @pnadolny13:

@aaronsteers the one things that not totally clear to me from reading the proposal is how the votes are conducted. Is the expectation that voting will happen during the live working group meetings?

I feel like we should probably allow for async voting too...

What do you think?

Thanks for this feedback! After meeting with our new Leading Members team (new page added on Leadership here in the PR), I've updated the proposal with the async voting details, as you propose. 👍

There's now a specific async voting and vote scoring process documented in the PR.

[dmosorast]

As mentioned in the Feb meeting, I'd like to propose that this not have any sort of language like "if any" to strongly encourage documenting the thought process that went through thinking about downsides, since there are always some kinds of downsides to any change (e.g., influencing a process towards a specific direction, less flexibility in some use cases, effects if someone is using a different language/platform/orchestration tech, etc.), and perhaps connecting this to alternatives, potential weaknesses, etc.

In this proposal, there aren't many clear downsides, other than the ever present scary unknowns. It might be worth poking holes in the potential weaknesses of the voting approach, maybe what happens if this process turns out to be too rigid, any potential for locking proposals in a back and forth, etc.

Otherwise, at least acknowledging the research that went into this SIP and the feeling that, given that, it is at least a good starting point would be good to mention here I think :)