Personal Pages

(DEPRECATED; see this instead: https://coda.io/d/_d17E7UZP-PU/Commons-Engine-Media-Framework_sursh) Commons Engine Media Framework

(back ups) Coda "Key Table" Prototypes (copied May 24, 2023; not synced)

Table Prototyping Scratchpad

Explore

(DEPRECATED; see this instead: https://coda.io/d/_d17E7UZP-PU/Commons-Engine-Media-Framework_sursh) Commons Engine Media Framework

See

Collective Media Framework⁠

(CMF) if desired for the source doc and explanatory preface.

Note: as of March 7, 2023, this is still insufficiently adapted in some places; work in progress.

⁠

General Policies

Freedom of Expression and Self-Organization

Expression

Commons Engine (CE) uses several tools such as

coda.io⁠

for digital networking and media management, as described in this document; however, we recognize our community’s power to communicate using whichever tools, times, levels of detail and style are mutually acceptable to senders and receivers!

Spontaneous communications may occur in or outside of any official channels and meetings, and that’s always fine unless it creates significant tensions or conflicts. (See also

Conflict Resolution Policy⁠

With that said, please be mindful of the effects that your personal dialogues will have on us, our mission and our community. Are you truly trying to help CE, in ways which will be inclusively open to critical feedback from others who aren’t currently in the conversation? If you develop recommendations for a larger team or group, will they be practical and accessible for their target audience? If so, your private and spontaneous dialogues can greatly help us. If not, please redirect your ideas using our official channels and policies.

Self-Organization

In addition to our General Policies, CE channels, teams and subprojects may develop additional internal standards, as long as those internal standards are compatible with our General Policies.

Examples:

We may develop special rules and guidelines to optimize our use of specific tools, including digital systems and subsystems.

We may develop special channels which are devoted to specific topics of interest to our general community.

Any teams and subprojects which we delegate authority to may create additional standards such as personal participation and availability standards. Likewise, any teams and projects which emerge within or use our channels, but have no authority in our general community, may create additional internal standards. (In the latter case, it might be especially important to practice awareness of the proper uses of community channels.)

* CE Community Agreement **

Please use

Commons Engine Community Agreement⁠

to proactively reduce cultural risks and to address tensions and conflicts.

* Data Security Policy **

integrate key points from

Internet and Data Policy⁠

(but, some or most of that will go into Media Management instead of General Policies)

Define & describe “Standard Security”, and add reference to

High Security Messaging⁠

below.

INCORPORATE:

Redundancy

Every important storage channel (including team documents and related items) should be backed up at least twice weekly, using one or more of the following methods:

exported by two or more collective Stewards or directly-appointed delegates thereof.

automatically backed up by a security system such as Google Backup & Sync, etcetera

Note that massive media files (especially video) may complicate efforts to consistently back up all data. (This is a good reason to define policies for file sizes and storage limits for the collective hosting of massive media files.)

Confidential and Private Data Security

Sensitive personal and financial information, etcetera-- particularly linked data and tables-- must be protected against accidental or deliberate damage.

Best practice is to isolate high security documents in separate drives with strictly limited sets of editors and viewers, defined by collective roles.

Specific ranges in tables can additionally be protected as needed; however, accurate maintenance of these protections is laborious; they’re probably only suitable for technically precise cases.

Supported Channels

This section is an overview of our officially supported communications channels.

Note that much of our communications may occur through spontaneous live dialogue, including in-person, telephone and teleconference communications. However, while supporting our Freedom of Expression policy, we also support structured live dialogue (Meetings, Co-Working and Office Hours) as well as the following asynchronous channels.

Meetings

Meetings may be in-person or via teleconference, and may be spontaneous (especially if brief) or scheduled.

The strengths and weaknesses of meetings are different from asynchronous/ written communications. Meetings are often superior for deeply discussing subjects. However, please don’t assume people will remember anything highly specific about a meeting! Establish shared understandings ahead of time, as necessary, regarding meeting recordings and/or note taking and reporting.

See

Event Planning and Management⁠

regarding the scheduling of important meetings.

Co-Working and Office Hours

During a co-working session, the participants separately work upon one or more clearly related activities to coordinate their attention, and they make themselves promptly available for each other’s questions and comments via one or more of the collective’s supported messaging channels.

We encourage co-working sessions for long-term, complex co-design processes.

Office hours are specific time periods during which people in specific positions are available for related dialogue (and potentially co-working sessions and meetings). Office hours are a valuable tool for some positions and relationships, especially ones which require both brief and lengthy creative dialogues and question-and-answer sequences.

Event Planning and Management

Fork

Inclusive Meeting and Event Framework⁠

if desired for an in-depth approach to the subject of meeting and event scheduling and/or design.

Note: The author has designed an "Inclusive Scheduling Form" as a spreadsheet; I think it's very useful, but not directly or automatically integrated with any calendar as of yet:

Inclusive Scheduling Template⁠

⁠

Calendars

All calendar usage should be directly coordinated whenever applicable with

Event Planning and Management⁠

. (add Coda & GCalendar interop protocol)

All Calendars

Directly link each Calendar Event as needed to related

Pages, Tables and Folders⁠

items.

Personal Calendars

Commons Engine teammates, especially those in major roles, should use personal CE calendars to track important personal and positional tasks as needed.

Team Calendars

Most team events should be shared in a general, private CE Calendar. Events may only be open to members of specific teams, when appropriate.

Public Calendar

The public calendar should list all events which the public is invited to view or participate in.

** Email

Note: Email is effective for official communications (because it’s an open append-only format), but it’s not an inherently high security messaging format. It’s not advisable to use unencrypted email to share passwords of any kind, or information which could dangerously compromise anyone.

Email Address Policies

Issuing Email Addresses

Everyone in an official CE position or team shall receive a commonsengine.org email address.

Some CE email addresses may also be issued to positions instead of individuals. Individuals may share access to such addresses on an as-needed basis.

These email addresses will never include personal names or initials, except possibly as defined below:

During transitional periods between outgoing and incoming holders of major positions, two temporary email addresses may be added to clearly distinguish between the outgoing and incoming person, throughout any period during which both persons have full access to the (normal, perpetual) positional email address.

These temporary addresses should be set up to always forward to the perpetual positional address, and vice versa, before issuing them.

The outgoing and incoming persons should send positional emails only from their temporary address throughout the period during which both persons have full access to the perpetual address.

The temporary addresses should be deactivated (not deleted) as soon as the outgoing person loses access to the perpetual address

We only send emails with our CE email addresses for official email business. We may, however, forward and BCC information to our CE addresses as needed.

All CE email addresses should be directly listed in our team directory.

Responsible Parties

One or more responsible parties should always be assigned to each email address, as follows:

The responsible party for a CE position is always the person assigned to that position. If more than one person holds that position, they may self-organize the turn-taking of the “responsible party” role.

It is the Responsible Parties’ duty to distribute emails further as necessary to support healthy and effective group processes.

Email Awareness

A responsible party should check each CE email address at least twice a week.

Responsible parties should read

ACTION NEEDED⁠

emails as soon as possible.

One or more persons should reply to CE emails if needed, at least partially, (such as “I’ll follow up in more detail later”, at least once per week.

Email List Governance

Commons Engine General Email List

A General Email List, if used, should include all opt-in interested participants in the CE community. This list could become large.

Unsubscribing: Friends who aren’t Project members should be able to remove themselves from this email list quickly and easily via a simple UNSUBSCRIBE request

Specialized Email Lists

Team emails: Team Stewards may use team email lists if desired. If Stewards use a team email list, it should include the personal email address of every mutually recognized member of that team. If you’re not sure whether someone is a member of your team, talk to them!

Other lists: CE and its teams may develop additional specialized email lists. For example, teams may send email updates to parties who are explicitly interested in specific events or topics.

Sending Emails

Consistently support our

General Policies⁠

Put “Commons Engine”, or the name of the CE team involved, at or near the beginning of the email subject line for business emails.

Team and Position Emails

Send all business emails to the team or position email address, if any; otherwise, use the personal email addresses for whoever holds the related position(s).

New Email Topics

Please do not bring new business into an existing email thread, unless it’s a casual FYI which you don’t intend to discuss! Instead, create a new email with an appropriate subject line.

Using Email Lists

For some functions, it’s appropriate for group emails to be sent only as BCC/ blind carbon copy. This is especially true for announcements which are not intended to create group dialogue. Consider this situationally.

Don’t share any email lists with anyone who isn’t on them, unless you have the permission of everyone on the list.

Official Announcements Policy

Key announcements, at a frequency between once weekly to quarterly, should be shared via our

CE General Email List⁠

Newsletter Policy

If we develop a periodic newsletter, it should be shared via our

CE Friends Email List⁠

, along with (if applicable) any other distribution methods such as printed copies.

Direct Messaging

Direct messaging-- including Signal, team chat and SMS, etc-- is useful for extremely time-sensitive announcements and quick Q&A sequences. Direct messaging is often a much better way to quickly get someone’s attention than email!

Design Document Comment Threads

Some design software, including Google Workspace and GSuite tools such as

Docs⁠

Sheets⁠

and

Drawings⁠

, enables users to select specific parts or regions of a media item-- for example, a section of text, or an object in a vector drawing-- and to directly attach comments and discussions to it. These comment threads can be a very helpful tool for teamwork which is focused on inclusively revising precise formal details of one or more prototypes.

* Team Chat

Sooner or later, we should establish a general media sharing and discussion network for all member-agents in good standing. (Perhaps Discord.) Such a general media network should enable all community members in good standing to create and discuss topics, and to share media either directly or via hyperlinks.

Team chat channels have less inherent structure than forums, encouraging free-flowing and practically “live” conversation which seems more comparable to live oral discussion.

Team chat can be helpful for daily chatting, “almost realtime” messaging, quick questions and interesting links. Team chat is especially designed for collaboration discussion, design and decision by mutually recognized teammates. Team chat is meant to provide a comprehensive “solution” for teamwork conversations. Therefore, each of the team's chat channels can smoothly integrate linked media, voice messages and teleconferencing options.

Creating Forum and Chat Channels

suggest basic channel creation policy here

suggest open channels by default, but private channels enabled for specific reasons

Private Channels

CE or its subprojects may have private channels, although depending on network capacity and type (distributed signaling & storage, etc) there may be little or no allowance for unauthorized creation of private channels. Governance Channel and (when applicable) Stewards Channel should be automatically authorized. (Governance for all Members; Stewards for all Stewards.)

*** Project Management

Our project management, via Coda, can be used to track officially identified issues and tasks which are attached to Commons Engine and any of our team, from developmental stages to completion and archiving.

* Developmental Staging

Use

Developmental Staging Recipe⁠

to extend project management “in both directions”

* Issues Log

Adapt

Issues Log Recipe⁠

to track occurrences of well-defined issues, including any actions or emergent conditions of special concern.

** Decision-Making Policy

Make decisions conversationally when feasible, but document them diligently. Use

Asynchronous Decision Policy⁠

if needed, in relation to important

Project Management⁠

decisions.

Social Media Outreach

Collective social media announcements should probably, in most cases, be direct copies of official broadcasts. (There are several ways to automate “cross-posting” if desired.) It’s difficult to inclusively put lots of effort and energy into unique messages for these platforms.

Establish activity level expectations guidelines. (higher for some platforms than others. i.e. if you have a public fb page but don’t post to it, viewership withers.)

Note that this is a costly and potentially risky responsibility!

Need clear standards for posting, especially shared external media, and especially staying away from "overreach" outside of collective identity.

Social Media Public Pages

Suggest activity level expectations guidelines. (higher for some platforms than others)

Note that this is a costly and potentially risky responsibility!

Need clear standards for posting, especially shared external media, and especially staying away from "overreach" outside of collective identity.

Suggest news feed distribution/multi-channel publication standards

Make it as simple & efficient as possible, through tools such as Wordpress provides

Highly desirable to have more than one admin for collective broadcasting channels!

High-visibility, daily to weekly public faces for official announcements and media-sharing. Currently recommended platforms below.

Facebook Page

Updates, news, and links relevant to collective followers. This is a one-to-many channel. To get something posted here, contact [collective email address].