Phase: Ideation

therebelrobot commented 8 years ago

_taken from opensourceway/open-decision-framework_

Steps you can take to be open Questions to ask Common flamewar triggers

Lead with transparency
• Publish a problem statement and possible approaches

• Identify any aspects of the project or decision that cannot be open

• Publish your ideation process

Build diversity of thought + an inclusive environment
• Engage internal customers and stakeholders early on, especially those who may disagree

• Seek out diverse perspectives (geographies, departments, levels)

• Champion collaboration and provide channels for feedback

• Address risks, limitations, and potential cultural impacts, especially with historically controversial issues

Begin to define roles + responsibilities • What is the potential impact on the organization? On the culture?

• Who do we need to include in planning?

• Whose problem are we trying to solve?

• Who will we need or want help from?

• Who else could be impacted?

• Who has solved a similar problem?

• Who is likely to disagree, dissent, reject, or opt out? Who else may care? There are a handful of issues that often generate controversy and upset within [Code for San Francisco], including:

• Decisions, policies, or changes that impact associates, such as rewards and wellness programs

• Changes to associates' work environment

• Implementation of proprietary technology

• Use of proprietary formats

• Data privacy and sharing

If your project or decision involves any of these themes, take extra steps to make your process open, inclusive, and transparent.

Key considerations

• Confidentiality, privacy, and regulatory requirements

• Potential to generate controversy

• Impact on [Code for San Francisco]'s culture and future decisions

• Where to publish

therebelrobot commented 8 years ago

So I'm going to be working through the specific portions of this process on this issue, and will update the main OP when the sections have ratification (I would say of at least 2 people for now, this may change going forward).

therebelrobot commented 8 years ago

Problem Statement

Documentation, communication, and release cycles are inconsistent across civic tech projects, leading to project distrust, an inability to partner with government agencies, and eventual project abandonment by the development team. Reignition of said projects takes much longer due to lack of documentation and supporting materials.

Possible approaches

Establish standards for documentation (inspired by ossmanifesto), communication and release policy
- Create easy-to-use tooling which streamlines bootstrap and conversion to new standard (command-line utilities, web interface)
- Outreach to groups to solicit feedback and improvement to standards and tools
- Government agencies
- Civic hacking groups
- Large OSS communities (node.js, golang, linux foundation, etc.)
- Companies that can benefit from consumption or contribution to OSS
Others?

Aspects that cannot (should not) be open

Any sensitive data (personal addresses, phone numbers, anything that can be used for doxxing or harassment)
Confidential feedback from business or governmental partners (NDAs, etc.)
Others?

Publish your ideation

way ahead of ya ;)

therebelrobot commented 8 years ago

Questions to consider

What is the potential impact on the organization? On the culture?
Who do we need to include in planning?
Whose problem are we trying to solve?
- The brigade organization, local governments, company partners, reimplementors, project new-comers, project consumers
- others?
Who will we need or want help from?
- Tech contacts in governments (SF OpenData, 18F, etc.)
- Tech contacts in partnering companies (Microsoft, Braintree, etc.)
- Open source contributors from various disciplines (Node, Python, Go, PHP, C++, etc.), particularly on larger projects that require good project management
- Devops specialists
- others?
Who else could be impacted?
Who has solved a similar problem?
- ossmanifesto
- Cohaesus/Labs-Standards
- others?
Who is likely to disagree, dissent, reject, or opt out? Who else may care?
- Casual developers, b/c of adding an additional item to their workflow, and requiring better documentation and participation
- Long-standing OSS contributors who have tried similar initiatives and for one reason or another stopped
- others?

therebelrobot commented 8 years ago

Issue moved to trustoss/trustoss-spec #1 via ZenHub.io

trustoss / trustoss.github.io

Phase: Ideation #1

Phase: Ideation

Problem Statement

Possible approaches

Aspects that cannot (should not) be open

Publish your ideation

Questions to consider

Steps you can take to be open	Questions to ask	Common flamewar triggers
Lead with transparency • Publish a problem statement and possible approaches • Identify any aspects of the project or decision that cannot be open • Publish your ideation process Build diversity of thought + an inclusive environment • Engage internal customers and stakeholders early on, especially those who may disagree • Seek out diverse perspectives (geographies, departments, levels) • Champion collaboration and provide channels for feedback • Address risks, limitations, and potential cultural impacts, especially with historically controversial issues Begin to define roles + responsibilities	• What is the potential impact on the organization? On the culture? • Who do we need to include in planning? • Whose problem are we trying to solve? • Who will we need or want help from? • Who else could be impacted? • Who has solved a similar problem? • Who is likely to disagree, dissent, reject, or opt out? Who else may care?	There are a handful of issues that often generate controversy and upset within [Code for San Francisco], including: • Decisions, policies, or changes that impact associates, such as rewards and wellness programs • Changes to associates' work environment • Implementation of proprietary technology • Use of proprietary formats • Data privacy and sharing If your project or decision involves any of these themes, take extra steps to make your process open, inclusive, and transparent.
	Key considerations
	• Confidentiality, privacy, and regulatory requirements • Potential to generate controversy • Impact on [Code for San Francisco]'s culture and future decisions • Where to publish