미디어위키 개발자가 되는 방법

From mediawiki.org
This page is a translated version of the page How to become a MediaWiki hacker and the translation is 62% complete.
Outdated translations are marked like this.
Languages:

이 문서는 개발자가 미디어위키 코어 및 미디어위키 확장 개발에 기여하는 데 필요한 기본 기술을 배우도록 돕기 위해 작성되었습니다.

위키미디어 개발을 시작하는 주요 경로는 멘토링을 제공하는 위키미디어 프로젝트에 기여하는 것입니다. 멘토링이 없는 대안은 좋은 첫 번째 버그를 수정하는 것입니다.

이미 미디어위키 개발에 익숙하다면, 개발자 허브 를 방문하십시요.

위키미디어 공동체에 참여하는 다른 방법을 보려면 기여하는 방법 항목을 참고하십시오.

개요

미디어위키는 위키백과, 위키백과의 자매 프로젝트, 그리고 전 세계 수천 개의 위키 사이트를 지원하는 소프트웨어입니다.

미디어위키는 PHP 프로그래밍 언어로 작성되었으며, 일부 지원 도구는 배치 파일, 쉘 스크립트, makefiles 및 파이썬 등을 포함하는 다른 언어들로 작성되었습니다.

Some supporting tools are written in other languages, including batch files, shell scripts, makefiles and Python.

MediaWiki는 주로 LAMP 플랫폼[1] 의 대부분의 운영 체제에서 실행됩니다. MediaWiki는 주로 MySQL 또는 MariaDB 데이터베이스 서버를 사용합니다.[2]

개발은 오픈 소스 스타일로 진행됩니다.[3]는 온라인에서 대부분 조정되고 Wikimedia Foundation에서 지원하지만 자원 봉사 커뮤니티 개발자도 큰 역할을 합니다.

메인 개발자 목록은 여기 있습니다. wikitech-l. 주요 개발자 IRC 채널은 #mediawiki connect 및 #wikimedia-dev connect입니다.

  • 소스 코드는 Git 개정 관리 시스템을 사용하여 관리되며 here에서 볼 수 있습니다. [4]

Find or create a task

Before you ever develop a feature or fix a bug in a MediaWiki project, it is important that you do your research about it. This includes:

  1. Search Phabricator if an open or closed Task (Document Types field) already exists. If it doesn't, create one. If this is a very small change, don't create one.
  2. Find and investigate the code that needs to be changed to implement the feature. Comment your findings on the Phabricator Task if they might be helpful to others who implement it or review your changes.
  3. Determine if you can likely add the feature or fix the bug based the code you investigated and the changes needed. If the task is large or complex, you should find something easier and work your way up to eventually be able to handle tasks of that size. If you believe you can complete it, assign yourself to the Task and begin working on it.

개발 환경 구축하기

Once you have found something you can work on, the next step to developing MediaWiki or an extension is creating an environment to run MediaWiki, its database, and any other external features so that you can develop and test them.

You can install and develop MediaWiki on Linux, Windows, or macOS using any of the three solutions below.

도커 개발 환경

  • MediaWiki Docker – Docker를 사용하여 MediaWiki를 실행합니다(Linux, Windows 또는 macOS 호스트에서 사용할 수 있음).

Docker is a good option if you want to setup a MediaWiki installation quickly and are not planning on installing many extensions.

You can also try the mwcli tool which sets up Docker with a few simple commands and provides basic orchestration functionality between MediaWiki, MySQL, ElasticSearch, Memcached, and other types of containers.

Vagrant 를 이용한 가상 머신

  • Vagrant 설치 — 이 단계는 Linux 가상 머신(Linux, Windows 또는 Mac 호스트에서 사용할 수 있음) 내부의 모든 요구 사항과 함께 MediaWiki 서버를 설치합니다.

Vagrant allows you start a MediaWiki instance you can develop as well as allowing you to add and develop any of 250+ extensions - all with a single command.

This saves you installation and configuration time compared to manually adding extensions in a Docker or local installation, but it runs a bit slower than the other two options.

수동 설치

MediaWiki can be developed by installing it and its dependencies locally on your system.

It will take much more time to set up than Docker or Vagrant.

  1. 매뉴얼:설치 요구사항 — Check hardware requirements and install dependencies
  2. Git에서 다운로드 — Git에서 최신 소스 코드를 다운로드합니다.
  3. 매뉴얼:설치 가이드 — 설치 및 초기 구성을 계속합니다.
  4. * 경고 및 오류를 조기에 표시하도록 환경에서 다양한 디버그 모드를 설정합니다.

Open a code editor

The two recommended code editors for editing MediaWiki are VSCode and PhpStorm. VSCode is free and PhpStorm is paid, however, you can acquire a PhpStorm license for free if you are a student by linking your GitHub Education account to your JetBrains account, or by requesting a license granted to Wikimedia.

To determine which editor you should install and use, know that all-around, PhpStorm has more and more-powerful features than VSCode. However, PhpStorm takes significantly longer to load on start than VSCode as it builds an index of the entire repository whereas VSCode progressively loads. Therefore, VSCode is typically useful for file-viewing sessions or small changes and PhpStorm for larger changes. It makes sense to have both installed for these reasons.

To develop the MediaWiki codebase that is inside a Docker container you can establish a remote connection to it and open the MediaWiki folder inside it using VSCode or PhpStorm.

Change and test the code

Change the code and view your changes by reloading your MediaWiki browser tab. Make sure to follow Manual:Coding conventions . Write and run tests on your code to make sure it works and is formatted properly.

Note, you can save time by ensuring your changes will be accepted before taking the time to write tests. Create a patch without needed tests and ask for someone to review it stating that you will add tests after they review it.

Create a patch

Finally, to submit your code to be reviewed and added to the repository you are contributing to, follow Gerrit/Tutorial .

커뮤니케이션 팁 및 지침

개발자가 조사, git 커밋, 검토 및 병합, Bugzilla 티켓 닫기(현재 파브리케이터 으로 대체)를 포함하여 MediaWiki 확장의 버그를 수정하는 모습을 지켜보십시오.

Follow these tips to communicate effectively and get help from community members.

Use Phabricator tasks effectively

When you plan to work on a Phabricator task:

  • No need to ask for permission: You can work on unassigned tasks without asking someone to assign them to you. There is no authority who assigns tasks or who needs to be asked first.
    • If a task already has a recent patch in Gerrit, choose a different task to work on instead.
    • If an existing patch in Gerrit has not been merged and has not seen any changes for a long time, you could improve that existing patch, based on the feedback in Gerrit and in the task.
  • Do your research: When you consider working on a task, do research before you start coding. Look at the code, try to understand what it is supposed to do, read related documentation, and try to find the places where you need to make code changes.
    • In a 파브리케이터 task, use the project tags in the side bar to find the code repository for the task.
    • If you have no idea at all how to fix the bug, consider finding an easier one first.
  • You do not need to announce your plans before you start working on a task, but you should communicate that you are working on the task.
    • When you start work, set yourself as task assignee by clicking Edit Task… in Phabricator, and set your Phabricator username in the Assigned To field. This communicates to others that you are working on it, so they don't duplicate work.
    • When your plans or interests change: If you are no longer working on a task, remove yourself as the assignee of the task. This tells others that they can work on the task, and they won't expect you to still work on it.
  • Follow Phabricator etiquette.
    • In Phabricator tasks, discuss only specific questions about the topic of that task. Don't use Phabricator to ask general questions, like how to set up a development environment or how to fix problems with Gerrit.

Compose good questions

  • Don't ask to ask...just ask!.
  • Be specific and provide context: Instead of simply asking "Can you give me more info?", "Please guide me", or "Please tell me how to start", include the following information in your question:
    • What are you trying to achieve?
    • What have you already tried? Copy and paste your commands and their output (if not too long) instead of paraphrasing in your own words.
    • What have you found out already during your research? Include links to code, documentation, or other resources you already consulted.
  • Use specific titles and subject lines in your communication. "Proposal draft" or "Need help" is not specific.
  • Keep conversations readable: When you reply in Zulip, in Phabricator tasks, or on mailing lists, only quote sections of previous comments that are relevant to your response. If you quote a complete previous comment, it makes threads hard to read.

Follow communication policies and best practices

Before you send or post your question:

Ask in the right place

  • Ask in public: Do not send private messages if your conversation topic is not secret. Private messages don't help others.
  • Ask and discuss in the best place:
    • In Phabricator tasks, discuss only specific questions about the topic of that task.
    • Ask general technical questions, like how to set up a development environment or how to fix problems with Gerrit, in the places listed on 커뮤니케이션 .
    • If you take part in an outreach program, then Zulip is for discussing questions about the outreach programs themselves.

Be patient

After you post your question:

  • Do not ask people for code review in a separate message. People receive Gerrit and Phabricator notifications and will respond when they can.
  • When seeking input and comments, especially during weekends and holidays, you may need to wait until business hours resume. On chat channels like IRC: if nobody answers, try again at a different time; don't just give up!
  • If you don't get an answer even after waiting and being patient, consider if other Communication channels might be a better place to ask your question.

부록

미디어위키 개발자들은 인도 방갈로르에서 일하는 중 입니다.

PHP

MediaWiki는 PHP로 작성되었으므로 MediaWiki의 핵심을 해킹하려면 PHP에 익숙해져야 합니다.

PHP 배우기
  • PHP 튜토리얼 — 다른 수많은 언어로 이용할 수 있습니다. PHP에 대한 지식은 없지만 다른 객체 지향 프로그래밍 언어로 프로그래밍하는 방법을 알고 있다면 PHP를 쉽게 배울 수 있습니다.
  • PHP Programming at Wikibooks.
  • PHP at Wikiversity.
PHP 리소스
알아야 할 것
  • 미디어위키의 maintenance/eval.php 스크립트는 미디어위키 객체와 클래스가 로드된 기본 PHP 인터프리터를 제공합니다.
  • 또한 MediaWiki의 maintenance/shell.php 스크립트는 PsySH를 기반으로 하는 maintenance/eval.php를 대체합니다. Manual:Shell.php

데이터베이스

많은 기능에는 어느 정도의 데이터베이스 조작이 필요하므로 MySQL/MariaDB에 익숙해야 하는 경우가 많습니다.

MySQL/MariaDB 배우기
MySQL/MariaDB 리소스
알아야 할 것
  • 당신의 MySQL/MariaDB 코드를 시험해 보세요.
    • 미디어위키는 현재 MySQL 및 MariaDB를 기본 데이터베이스 백엔드로 사용합니다. PostgreSQL 및 SQLite와 같은 다른 DBMS도 지원합니다. 그러나 거의 모든 개발자는 MySQL/MariaDB를 사용하고 다른 DB를 테스트하지 않기 때문에 정기적으로 중단됩니다. 따라서 특별히 다른 DB에 대한 지원을 개선하려는 것이 아니라면 패치를 테스트할 때 MySQL/MariaDB를 사용하는 것이 좋습니다. 후자의 경우 MySQL/MariaDB가 손상되지 않도록 주의하십시오(또는 끔찍하게 비효율적인 쿼리 작성). MySQL/MariaDB는 모두가 사용하는 것이기 때문입니다.

자바스크립트와 CSS

JavaScript와 CSS는 프론트 엔드 코드에서 어디에나 존재합니다. MediaWiki에서 작업하기 위해 JavaScript, jQuery 및 CSS에 익숙할 필요는 없지만 작업하기로 선택한 항목에 따라 필요할 수도 있습니다.

자바스크립트와 CSS 배우기
자바스크립트와 CSS 리소스

MediaWiki

MediaWiki 코드 기반은 크고 일부는 보기 흉합니다. 그것에 압도되지 마십시오. 처음 시작할 때 기능을 작성하거나 코드의 작은 영역에만 영향을 미치는 버그를 수정하는 것을 목표로 하십시오.

미디어위키의 기본과 필독서
  • MediaWiki 아키텍처 — MediaWiki의 주요 구성 요소와 이들이 서로 어떻게 작동하는지에 대한 높은 수준의 개요입니다.
  • 개발자를 위한 보안 — 보안 코드를 작성하는 이유와 방법에 대한 개요입니다.
미디어위키 리소스
  • Manual:Code — 중요한 파일 목록과 더 자세한 정보에 대한 링크.
  • 메뉴얼:훅 — 후크 목록입니다. 코드베이스의 어떤 부분이 어떤 작업을 수행하는지 찾으려는 경우 관련 후크를 검색하는 것이 좋은 출발점인 경우가 많습니다.
  • Manual:Coding conventions — 미디어위키 커뮤니티의 일반적인 코딩 규칙에 대한 개요입니다.
  • 코드 문서 (class reference) — 코드 및 코드 주석에서 자동으로 생성된 문서.
  • Manual:How to debug — 미디어위키 디버깅 가이드
  • Manual:Eval.php — 라이브 미디어위키 개체와 상호 작용하는 도구입니다.

미디어위키 확장기능

미디어위키 확장 코드에서 작업하기로 선택한 경우 다음 링크에서 추가 정보를 제공합니다.

미디어위키 확장 기본
미디어위키 확장 리소스

MediaWiki skins

메뉴얼:미디어위키 스킨 만드는 방법 is helpful if you choose to work on MediaWiki skins.

같이 보기

Footnotes

  1. ↑ MediaWiki는 PHP를 지원할 수 있는 대부분의 플랫폼에서 실행되지만 특정 유틸리티나 운영 체제 기능이 없는 비 LAMP 플랫폼에서 MediaWiki 기능이나 성능이 제한될 수 있습니다.
  2. ↑ MediaWiki는 PostgreSQL, SQLite를 포함하여 MySQL 및 MariaDB 이외의 DBMS를 지원합니다.
  3. ↑ 개발자는 다양한 조직의 자원봉사자와 유급 직원(또는 계약자)이 혼합되어 있습니다. MediaWiki 코드 작업의 전체 목록을 보려면 Developers 기사를 읽어보세요.
  4. ↑ https://phabricator.wikimedia.org/diffusion/에서 소스 코드 및 코드 리포지토리의 개정판을 검색하거나 Gerrit를 사용하여 시스템에 소스 코드를 다운로드하십시오.
Retrieved from "https://www.mediawiki.org/w/index.php?title=How_to_become_a_MediaWiki_hacker/ko&oldid=6064071"