/meta

Other repos are for the PhRUG projects. This repos is for THE PhRUG project. This is where we discuss PhRUG itself.

meta

Other repositories are for the PhRUG projects. This repository is for THE PhRUG project. This is where we discuss PhRUG itself.

We try to run the community openly, transparently, through this repository. The idea is to increase the bus factor, make it easier to work asynchronously, distribute workload, and reduce burnout among the community organizers.

The repository is patterned after the yarn RFCS repository. We'll also follow a similar process.

Communications Guidelines

  • Use phackers.slack.com for casual real-time communications. Discuss public matters in #ruby, not-for-public topics in #phrug-organizers (DM Rad or Terence for an invite). Use your discretion, but prefer the public channel as much as possible.

Longer discussions should use this RFC process. Doing it this way helps us in many ways:

  • it is easier to revisit the discussion later
  • it lets us work asynchronously
  • it makes it easier for other community members to join in the discussion

The PhRUG RFC Process

  • Fork the repo https://github.com/phrug/meta
  • Copy 0000-template.md to accepted/my-project-or-idea.md (where 'my-feature' is descriptive. don't assign an RFC number yet).
  • Fill in the RFC. Put care into the details
  • Submit a pull request. As a pull request the RFC will receive feedback from the larger community, and the author should be prepared to revise it in response.
  • Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments.
  • The RFC author is not obligated to implement it. However during the RFC feedback cycle, the project members, action items, and timetables should be defined. An RFC will not be accepted until these are clearly defined.

This process should not stifle community initiatives. We follow this to document what we plan to do, what we have done, and why, to guide future members of the community.

Whenever there are disagreements, we should try to distinguish between disagreements on style and substance. As long as the RFC does not hurt the community or anyone in the community, we should let the RFC author's style prevail. It is a community project and the RFC author's time that is at stake more than anything else.