kısayol: Gerrit/+2

Gerrit/Ayrıcalık politikası

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page Gerrit/Privilege policy and the translation is 100% complete.
Other languages:
English • ‎Türkçe • ‎français • ‎日本語

Haklar ve sorumluluklar

Çoğu Wikimedia Gerrit deposu, bir kullanıcı "+2" kod incelemesi verdiğinde, Jenkins, testleri çalıştırdıktan sonra değişikliği otomatik olarak birleştirecek şekilde yapılandırılmıştır. Bu yüzden +2 kod incelemesi verme hakkı, özellikle Gerrit grupları olmak üzere insanlarla sınırlıdır. Tipik olarak, her deponun adını taşıyan ve bu depoya ayrıcalıklar veren bir Gerrit grubu vardır. Ayrıca, bazı Gerrit grupları birden çok depoda ayrıcalıklar verir. En önemlisi, mediawiki grubu, MediaWiki çekirdeği ve tüm uzantılar ve görünümlerin yanı sıra MediaWiki ile ilgili diğer depolarda ayrıcalıklar verir.

Gerrit grupları üyelerini LDAP gruplarından türetebilirler. Çoğu WMF çalışanı, LDAP'de otomatik olarak mediawiki grubuna üye olan wmf grubunda yer alır.

Gerrit hizmetlileri, Gerrit gruplarına üye ekleyebilir ve gruplardan üye çıkarabilir.

MediaWiki çekirdeğindeki bir değişikliği veya Wikimedia tarafından dağıtılan bir uzantıyı birleştirmek büyük bir iştir. Değişiklik, Gerrit olarak birleştirilir birleştirilmez sanallaştırılmış bir hazırlık ortamı olan Beta Kümesi otomatik olarak dağıtılacaktır. Ayrıca, sürüm dalı kesilmeden önce geri döndürülmediği sürece bir sonraki MediaWiki çekirdek dağıtım penceresinde (Dağıtımlar'a bakınız) otomatik olarak alınacaktır.

Birleştirmeniz Vikipedi veya diğer sitelerin başarısız olmasına neden olabilir. Saldırganların verileri silmesine veya bozmasına ya da özel bilgilere erişim sağlamasına olanak tanıyan bir güvenlik açığı oluşturabilir. Ve daha yaygın durumda, kodun testleri yoksa, kötü uygulanmışsa veya yetersiz sosyalleştirilmişse, technical debt artmasına neden olabilir. +2'yi kullanmadan önce bu belgeyi ve ilgili tüm politikaları dikkatlice okumalısınız.

+2 güçlü bir güven ifadesidir ve güven, sağduyu ve dikkatli hareketle sürdürülür.

Kod incelemesinde, tasarım tartışmalarında ve hata yorumlarında, +2 gücüne sahip olanlar, başkalarının bakış açısından görmek konusunda özel bir sorumluluğa sahiptir.

İnceleme olmadan birleştirme

Kodu gözden geçirmeden birleştirmek kod kalitesi için kötü ve moral açısından kötüdür. +2 hakların amacı geliştirme ve kod incelemesini ayırmaktır. Gerrit'teki bir değişikliği birleştirmenin amacı dünyaya "Evet, bu değişikliğin MediaWiki kurallarını, iyi mühendislik uygulamalarını takip etmesini ve mantıklı olmasını sağladım" demektir. (Cf. "Kod İncelemeleri: Just Do It", Jeff Atwood.) Satır içi yorumlar, kodla birleştirilmeden önce ele alınması gereken sorunları belirtmek için kullanılabilir.

Bir gözden geçirenin onayı olmadan kendi kodunuzu birleştirmek, ayrıcalıkların iptali için gerekçe olabilir.

Bu, size ait bir Gerrit değişikliğine +2 vermekle aynı şey değildir. Örneğin:

  • Bir değişiklik bir gözden geçirenden +2 alırsa, ancak Jenkins derlemesi başarısız olursa, sahibin derleme işini yeniden başlatmak için +2 vermesi gerekebilir.
  • Geri döndürmeler, geri aldığı kaydetme yeni olduğu sürece genellikle kendi kendine birleştirilebilir. Muhtemelen o sırada gözden geçirilmiş bir sürüme geri dönüyorsunuz.
  • Dağıtım dallarda ve Puppet deposunda değişiklikler, aynı zamanda yazar olan dağıtımı yapan kişi tarafından birleştirilir. Bu durumlarda, kod incelemesi genellikle değişikliğe +1 verilerek belirtilir.
  • Gerrit'te bir taahhüdün iki yazarı olabilir: bir sahibi ve bir değişikliği yükleyen bir gözden geçiren. Tipik olarak, sahip ve gözden geçiren her biri diğerinin çalışmasını inceler. Tüm değişiklikler gözden geçirilip onaylandığı sürece taahhüt birleştirilebilir.

Çok az değişiklik, kendi kendine birleşecek kadar önemsizdir. Önemsiz belgelendirme değişiklikleri veya yalnızca bir bakıcılı projeler gibi bazı durumlarda kendi kendine birleştirme uygun edilir.

Wikimedia kümesine konuşlandırılmayan uzantılar (ve diğer projeler) için, kod inceleme politikası uzantının sahibi ya da yazarına bağlıdır. Bazı Wikimedia dışı uzantılar, Wikimedia'nın kendi kendine birleşmeleri yasaklayan politikasına uyar, ancak buna gerek yoktur. Uzantıyı yazan tek kişi sizseniz ve değişikliğinizi inceleyecek kimse yoksa veya uzantı terkedilmişse, değişikliklerinizi kendi kendine birleştirmeniz kabul edilebilir.

Takım içi inceleme ve paylaşılan sahiplik

Bir ekibin parçası olarak çalışıyorsanız, ekibinizin üyelerinin incelemesine yalnızca izin verilmez, aynı zamanda şiddetle tavsiye edilir. Meslektaşlarınızın kodunuzu sürekli olarak incelemesini sağlamak, geliştirme ivmesini sürdürmek ve incelemecilerinizin yaptığınız işe aşina olmasını sağlamak için harika bir yoldur.

Ekip içi inceleme yaparken, özellikle kör noktalar, bilişsel önyargılar ve bulunduğunuz grup dışındaki büyük değişiklikler için satın alma ihtiyacı konusunda hassas olun. MediaWiki de dahil olmak üzere çoğu açık kaynaklı proje, süslü yeni soyutlama katmanları, görünüm sistemleri, test çerçeveleri vb. oluşturmak için terk edilmiş çabalarla doludur. Değişikliklerinizin ekosistem üzerindeki etkisini bir bütün olarak düşünün ve yorum talepleri, wikitech-l, IRC ve diğer mekânlar aracılığıyla sohbetlere katılın. Paylaşılan kod sahipliği (daha fazla veya daha az derecede), yaptığınız şeyin uzun vadeli bir değere sahip olmasını sağlamaya yardımcı olur.

Kod gözden geçirenler için okunmalıdır

Gerrit ayrıcalıklarını isteme

To request membership in the mediawiki group, create a new task under the MediaWiki-Gerrit-Group-Requests project in Phabricator. Then send an email to the wikitech-l mailing list.

To request membership in another group, create a new task under the Gerrit-Privilege-Requests project in Phabricator.

In either case, the Phabricator task should specify:

  • Gerrit username
  • repository or repositories to which access is required
  • reasoning, including links to patches written and reviewed

Developers commenting on a privilege request should consider whether the applicant has contributed high quality patches, has exercised +1 rights well, and has demonstrated competence. Negative comments should be written with tact, they should not be overly strident.

If there is a consensus of trusted developers on the Phabricator task, any of the Gerrit administrators can resolve the request. The task must remain open for at least a week, to allow interested developers to comment. Additional time should be allowed if the request is open during travel or holiday periods.

If there is no consensus on a request in Phabricator, it may be referred to TechCom for adjudication.

Previously, some extension maintainers were given ownership rights on the relevant project in Gerrit, so that they could add new group members without making a request in Phabricator. This model should not be used for new extensions. Gerrit administrators should not grant repository ownership to ordinary developers. Before an extension is deployed to the Wikimedia cluster for the first time, the rights should be audited, and legacy ownership privileges should be downgraded to +2 access.

Güvenilir kuruluşlar için hızlandırılmış süreç

Gerrit hizmetlileri, özellikle ilgili grupların verilmesi ve iptal edilmesi için aşağıdaki güvenilir kuruluşlardan gelen talepler üzerine derhal harekete geçebilir:

Organizasyon Yönetilen gruplar
Wikimedia Deutschland wmde, wmde-mediawiki
ShoutWiki ShoutWiki, Brickimedia
Hallo Welt! bluespice
WikiTeq WikiTeq

It is not necessary to file a Phabricator task or demonstrate consensus.

This facility is intended to allow these organisations to rapidly on-board staff members, who are assumed to be trusted by virtue of the hiring process. It also allows trusted organisations to grant access to volunteers who are well known and trusted by those organisations.

WMF employees may be added to the wmf group in LDAP when they are hired. Wikimedia Deutschland employees may be added to the wmde group in LDAP when they are hired.

TechCom, or the CTO in consultation with TechCom, may direct a Gerrit administrator to add any person to a Gerrit group.

İptal etme

Revocation of Gerrit rights is permitted in the following circumstances:

  • In an emergency, such as a compromised account, Gerrit administrators may revoke access immediately, at their discretion. Reversal of emergency revocation may be done at the administrator's discretion if the emergency is judged to have passed. TechCom, or the CTO in consultation with TechCom, may review an emergency revocation and direct its reversal.
  • Revocation of privileges of a WMF employee may be directed by that employee's manager, in consultation with WMF Talent and Culture, as discussed in the Staff Handbook.
  • Revocation of privileges from any person may be directed by TechCom, or by the CTO in consultation with TechCom.

The reasons for revocation may include:

  • Merging bad code
  • Merging your own code without review
  • Failing to socialize high impact changes within the development community
  • Not following the guidelines above
  • Inappropriate behaviour, in particular, violating the Code of Conduct
  • Termination of employment or contract

It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work. Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied. If departed staff members wish to continue to contribute in a volunteer capacity, they may reapply for access by the usual process.

İptal isteğinde bulunma

Emergency revocation should be requested by directly contacting a Gerrit administrator, for example using IRC. Revocation for reasons of competence or behaviour should generally be handled in private, following a defined escalation path. For more details, refer to the following table:

Plan Eylem
  • A developer uploads and self-merges plainly malicious code.
  • Contact a Gerrit administrator for emergency revocation.
  • A developer shows a pattern of merging flawed changes, without proper review.
  • A developer repeatedly merges their own code, in violation of community norms.
  • If the developer is an employee of WMF or a trusted organisation, report the problem to their manager.
  • If the manager's response was unsatisfactory, or if the developer is not an employee, report the problem to TechCom.
  • If TechCom's response is unsatisfactory, you may report the problem to the CTO.
  • A developer uses their +2 access to bully or intimidate developers seeking review.
  • Other behaviour issues or Code of Conduct violations.
  • If the developer is an employee of WMF or a trusted organisation, and you feel comfortable doing so, report the problem to their manager.
  • Otherwise, report the problem either to TechCom or to the Code of Conduct committee.
  • If the committee's response is unsatisfactory, you may report the problem to the CTO.

Bu politikada yapılan değişiklikler

Bu politikadaki değişiklikler, TechCom'a danışarak CTO tarafından onaylanmalıdır.

Tanımlar

CTO
The Chief Technology Officer of the Wikimedia Foundation.
TechCom
The Wikimedia Technical Committee. For TechCom to decide or direct something means that a meeting of the committee, by remote audio/video conference or in person, with the attendance of a quorum of at least half of TechCom's members, passes a resolution by simple majority or unanimous consent.