Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The tasks, roadmap, and workings of the Frontend Working Group are open to the Open edX Community. In the spirit of this, our communications should inclusively take place in an inclusive way. This means preferring asynchronous over synchronous and public over private.

...

The group is currently in the process of moving towards a more asynchronous approach, with the intent of not only reducing the need for synchronous working sessions , but to transmute those that remain into meet-ups. (Which tend tends to be less frequent but more generally interesting: show-and-tell and discussions around emerging technologies, rather than just discussing problems.)

A lof lot of this already happens naturally in Github, the forum, or in this wiki, but because not everybody subscribes to those, the nexus of this asynchronous communication will be the #wg-frontend channel on Slack. Whenever anything important is happening, regardless of venue, it will be linked to publically in the group’s channel, so that:

...

  1. Prefer to have discussions in the public channel, rather than in private: this makes us more open, and thus, more inclusive, with all the advantages that that bringsbring;

  2. Because of item 1, it’s okay to tag specific people on in your public messages. A private message is no less annoying, and it can never be as directfully directly useful to the community at large as a public one.

  3. If a discussion is particularly important, document it in a more permanent and accessible medium such as in a forum thread, a wiki page, or an issue (maybe even an OEP or ADR!) in the appropriate repo on Github. Slack is great for fast, efficient communication, but really bad at grouping and indexing it for future reference.

...

In practice, with lazy consensus, an individual may make a proposal propose with adequate supporting details and state that, without explicit objection, the proposal will start to be implemented within a reasonable amount of time (e.g., 72 hours) to allow other members of the Frontend Working Group to review the proposal and to make any relevant objections. This approach ensures enough time is allotted to account for differing time zones and asynchronous review of proposals.

...