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

How to propose big ideas and/or big changes #43

Open
MeltyBot opened this issue Jan 24, 2022 · 1 comment
Open

How to propose big ideas and/or big changes #43

MeltyBot opened this issue Jan 24, 2022 · 1 comment

Comments

@MeltyBot
Copy link

Migrated from GitLab: https://gitlab.com/meltano/handbook/-/issues/49

Originally created by @aaronsteers on 2022-01-24 11:49:39


Following from recent discussions, I want to discuss and ultimately document ideas for best practices regarding how team members can most effectively raise big ideas or propose big changes.

A step-wise approach

One proposal is as discussed in https://gitlab.com/meltano/meltano/-/issues/3139#note_819354262, which is to try to make sure issues/challenges are logged before the solution. And also, we want the first iteration of the discussion to remain high level and accessible.

Here's a start we could iterate from:

...breaking into smaller parts, and logging separate issues for these important steps:

  1. log the problem statements and challenges as simply as possible in dedicated issues
  2. start a concise entry-level discussion on "should we build ___?", and
  3. after initial discussions and/or prioritization, a longer write-up, something akin to Amazon's "six pager" version as a detailed plan and discussion.

Other techniques for async (to be expanded with examples)

  1. As much as possible, starting with concise problem statements and descriptions of proposed changes. Again, in most cases, for big topics, the problems should probably be logged separately from the proposed solution(s).
  2. Avoid buzzwords, best practices, and philosophy as reasons-to-build.
    • Avoid: "We need to build X because we need to be DRY."
    • Avoid: "In order to be DRY, we need to build X."
    • OKAY: "I like X because its DRY."
    • OKAY: "An added benefit of X is that it is more DRY."
  3. Avoid heightening language in issues. (Instead, log issues as neutrally and factually as possible, then escalate over other channels as needed.)

What needs prioritization, what does prioritization mean

If we use a concise entry-level discussion issues for big topics (listed as a proposed step 2 above), then perhaps the more detailed write-up, along with requesting more detailed feedback from the full team, would be natural next steps after prioritization.

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

No branches or pull requests

1 participant