Hi,

at the CSM Workshop at SUSE we discussed how to update the current SUSE Ruby style guide [1] to reflect the experience we gained since its introduction and also real-world Ruby usage. We agreed on the following:

  1. The style guide should have a maintainer, who will be responsible
     for its text and for processing and incorporating changes proposed
     by others. Maintainer's decisions should generally reflect the
     prevailing opinions of SUSE/openSUSE Ruby developers as they will
     express them.

     I volunteered to be such maintainer, which was accepted by
     everyone present.

  2. There should be a clear process to introduce changes, which would
     allow everyone interested to participate, but which would also be
     light-weight and which would not cause additional delays. The
     process proposal we agreed on is outlined below.

  3. SUSE Ruby developers will meet at future CSM Workshops whenever
     they feel the need to discuss changes in the style guide in
     person. Proposed changes resulting from such discussions will then
     still go through the formal process like all other changes.

Please have a look at the process proposal and let me know if you have any comments. After the discussion I'd like to put the final process description into the style-guides repository. Then I'd like to use the process to propose some specific changes to the specification, which we also discussed at the CSM Workshop.

Thank you.

Style Guide Update Process
--------------------------

Anyone interested can propose a change to the Ruby style guide. Such person is called an *initiator*. The process is as follows:

  1. The initiator creates a pull request against the style guide on
     GitHub with the proposed change.

  2. The initiator announces the proposed change at:

       - [email protected]
       - [email protected].

  3. SUSE/openSUSE Ruby developers will discuss the proposed change
     (either at the pull request on GitHub, or in the mailing lists),
     possibly expressing their agreement, disagreement and requests for
     modifications. This discussion will be overseen by the maintainer,
     who will work with the initiator to adapt the proposed change as
     necessary.

  4. Based on the discussion, the maintainer will decide either to
     merge the pull request or reject it. He will announce his decision
     as a reply to the original e-mail announcement of the proposed
     change.

[1] https://github.com/SUSE/style-guides/blob/master/Ruby.md

--
David Majda
SUSE developer
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]

Reply via email to