Соглашения о содействии открытому исходному коду

Очевидно, безопасность является огромным фактором для такой среды, как Rails. Наличие другого протокола имеет смысл, и если у вас есть библиотека, которая имеет важные соображения безопасности, у вас должен быть надежный способ сообщить о них.

Все другие вопросы

Если проблема не связана с безопасностью, то можно использовать Github Issues. Основная команда, будучи удивительными людьми, создала кучу шаблонов, чтобы помочь репортерам создать исполняемый контрольный пример для данной проблемы. Вот шаблон выпуска Active Record:

begin
  require "bundler/inline"
rescue LoadError => e
  $stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler"
  raise e
end

gemfile(true) do
  source "https://rubygems.org"
  # Activate the gem you are reporting the issue against.
  gem "activerecord", "5.0.0"
  gem "sqlite3"
end

require "active_record"
require "minitest/autorun"
require "logger"

# Ensure backward compatibility with Minitest 4
Minitest::Test = MiniTest::Unit::TestCase unless defined?(Minitest::Test)

# This connection will do for database-independent bug reports.
ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")
ActiveRecord::Base.logger = Logger.new(STDOUT)

ActiveRecord::Schema.define do
  create_table :posts, force: true do |t|
  end

  create_table :comments, force: true do |t|
    t.integer :post_id
  end
end

class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

class BugTest < Minitest::Test
  def test_association_stuff
    post = Post.create!
    post.comments << Comment.create!

    assert_equal 1, post.comments.count
    assert_equal 1, Comment.count
    assert_equal post.id, Comment.first.post.id
  end
end

Это отличная идея и способ действительно помочь кому-то сообщить о проблеме. Это позволяет другим быстро воспроизвести проблему, которая приведет к гораздо более быстрому разрешению.

Запросы функций

Запросы на функции не сообщаются как проблемы для Rails. Вместо этого ожидается, что запросчик напишет код для функции и отправит его как вклад. Это имеет смысл, поэтому запрос новой функции подпадает под руководство по новому вкладу.

Помогая решить существующие проблемы

Прекрасный способ внести свой вклад в любую библиотеку, включая Rails, — это просмотреть открытые проблемы и попытаться подтолкнуть их к решению. Например, выберите проблему и попытайтесь воспроизвести ее. Если участник следовал соглашению, должен быть исполняемый контрольный пример.

Если кто-то отправил исправление с помощью запроса извлечения (PR), вы можете проверить PR и проверить исправление.

В обоих случаях вы помогаете основной группе, проверяя, что все так, как сообщается, позволяя им преодолеть затруднения и приступить к их устранению.

Если вы собираетесь предложить элемент с открытым исходным кодом, подумайте о помощи, которую вы можете использовать, помимо нового кода. Могут ли люди тестировать новые функции и сообщать об ошибках? Могу поспорить, что они могут, и это является более низким барьером для входа для многих людей.

Внести вклад в документацию по Rails

В Rails есть целый раздел, посвященный тому, чтобы просто внести свой вклад в документацию фреймворка. Опять же, это то, чему должны научиться новые открытые источники. Как документируется ваша библиотека? Это ясно и легко найти? Кроме того, как другие могут улучшить ваши документы? Убедитесь, что вы ответили на эти важные вопросы.

В большинстве случаев вам не потребуется документация на уровне, предлагаемом Rails. Он массивный и используется десятками тысяч (если не больше) людей по всему миру. Но дело в том, чтобы получить хороший ответ для вашей документации. Я могу сказать вам, что я пытался выпустить библиотеку с очень тонким README в качестве документации, и она не удалась.

Перевод документации

Если вы ожидаете, что вашей библиотекой с открытым исходным кодом будут пользоваться люди, говорящие на разных языках, возможно, было бы неплохо иметь простой способ перевода документов. Rails делает это, прося переводчиков создать новый каталог с именем языка, скопировать в существующие документы и перевести их.

Вклад в исходный код

И мы пришли к сути того, о чем думает большинство людей, внося свой вклад в открытый исходный код: коду. Как и следовало ожидать, этот раздел руководства является самым длинным.

Настройка локальной среды

Первое, что хочет сделать любой участник, это выяснить, как запустить ваш код локально. Если они не могут сделать это легко, они не могут внести свой вклад легко, и вы отворачиваете помощников.

 Short summary (ideally 50 characters or less)

More detailed description, if necessary. It should be wrapped to
72 characters. Try to be as descriptive as you can. Even if you
think that the commit content is obvious, it may not be obvious
to others. Add any description that is already present in the
relevant issues; it should not be necessary to visit a web page
to check the history.

The description section can have multiple paragraphs.

Code examples can be embedded by indenting them with 4 spaces:

    class ArticlesController
      def index
        render json: Article.limit(10)
      end
    end

You can also add bullet points:

- make a bullet point by starting a line with either a dash (-)
  or an asterisk (*)

- wrap lines at 72 characters, and indent any additional lines
  with 2 spaces for readability