ا새로운 개발자들을 위해

From mediawiki.org
Jump to navigation Jump to search
This page is a translated version of the page New Developers and the translation is 99% complete.

이 페이지는 Wikimedia 신규 개발자를 위한 간단한 안내 랜딩 페이지입니다. 이는 신규 개발자 이니셔티브의 일환입니다.

참여하기 위한 다른 옵션은 기여하는 방법 을 참조하십시오.

환영합니다!

Wikimedia Hackathon 2019 참가자

Wikimedia 코드 작업을 하고 싶은데 어디서부터 시작해야 할까요?

Wikimedia의 기술 커뮤니티는 항상 새로운 프로젝트 기여자를 환영하고 있습니다.

글로벌 커뮤니티의 일원이 되어 모든 사람이 더 쉽게 무료 지식을 접할 수 있도록 도와주세요!

Wikimedia에 기여하는 과정은 4단계입니다:

  1. 소프트웨어 프로젝트 선택
  2. 개발 환경 구축하기
  3. 작업 선택 및 해결 (코드 쓰기 및 테스트)
  4. 코드 변경 사항 제출

알아야 할 몇 가지 기본 사항

이미 자유 및 오픈 소스 소프트웨어 문화에 익숙하다면 이 섹션을 건너뛸 수 있습니다.

Wikimedia는 다양한 분야에 수백 개의 소프트웨어 프로젝트를 가지고 있습니다. 개요를 보려면 이 슬라이드를 확인하십시오.

각 소프트웨어 프로젝트의 유지관리자는 원하는 인프라를 자유롭게 선택할 수 있습니다. 일반적으로, 기본적으로 모든 소프트웨어 프로젝트는

  • 소프트웨어 버그 및 개선 요청을 보고, 관리 및 논의하는 작업 추적 도구가 있습니다. 예를 들어 Wikimedia Phabricator, GitHub 또는 Sourceforge가 있습니다.
  • 모든 사람이 소스 코드를 "체크아웃"할 수 있는 코드 저장소가 있습니다. 예는 Wikimedia Git/Gerrit, GitHub 또는 Sourceforge입니다.
  • 제안된 코드 변경(소위 패치)이 논의되고 개선되는 코드 검토 도구가 있습니다. 예로는 Wikimedia Git/Gerrit, GitHub 또는 Sourceforge가 있습니다. 제안된 패치가 양호하고 코드 리포지토리에 병합되면 모든 사람이 코드 변경 사항을 사용할 수 있게 됩니다. (여기에서 코드 검토를 위한 모범 사례에 대해 자세히 읽을 수 있습니다.)
  • 소프트웨어 프로젝트 및/또는 도움과 지원을 받기 위한 일반적인 토론 장소가 있습니다. 이러한 장소는 메일링 리스트, IRC 채팅 채널, 위키 페이지 또는 기타 장소가 될 수 있습니다. 정확한 장소는 각 프로젝트에 따라 다릅니다. 사용자 페이지의 "이 사용자에게 이메일 보내기"을 통해 특정 멘토에게 연락할 수도 있지만 "비공개 질문은 다른 사람에게 도움이 되지 않습니다".

언제든지 문제가 발생하거나 도움이 필요하면 요청하십시오. 적절한 장소에서 좋은 질문을 하고 싶다면 "피드백, 질문 및 지원" 섹션을 읽는 것이 좋습니다.

소프트웨어 프로젝트 선택

권장되는 시작 방법입니다. 다음 프로젝트 중 하나를 선택하고 프로젝트 설명서에 따라 개발 환경을 설정하고, 작업할 작업을 선택하고, 작업을 해결하고, 검토를 위해 코드 변경 사항을 제출하십시오:

Huggle

Screenshot

Wikimedia 프로젝트를 위한 기물 파손 방지 데스크탑 애플리케이션

Kiwix

Screenshot

Wikipedia 웹 콘텐츠용 오프라인 리더

안드로이드용 커먼즈 앱

Screenshot

Wikimedia Commons에 사진을 업로드하는 Android 기기용 앱

위키 교육 대시보드

Screenshot

Wikipedia 교육 과제를 지원하고 강사와 학생을 위한 데이터 및 코스 관리를 제공하는 웹 애플리케이션

ORES logo ORES

ORES highlights problematic edits

Wikimedia 프로젝트에 머신 러닝 서비스를 제공하는 웹 서비스 및 API입니다. 기계 예측은 기물 파손을 포착하고 기사 품질을 측정하며 다른 위키 작업을 지원하는 데 사용됩니다.

라이브러리 카드 플랫폼 (The Wikipedia Library)

Screenshot

tool 위키미디어 기여자가 paywalled 리소스에 대한 무료 액세스를 신청할 수 있습니다.

Logo 파이위키봇

Terminal

MediaWiki 사이트에서 작업을 자동화하는 Python 라이브러리 및 스크립트 모음.

Logo AfC 도우미 스크립트

Screenshot of the AfC Helper Script in use

사용자 스크립트는 Wikipedia의 초안 문서를 검토합니다.

Logo VideoCutTool

Screenshot

Wikimedia Commons에서 비디오를 편집하는 도구입니다.

당신은 관리자이고 당신의 프로젝트가 위의 소프트웨어 프로젝트 목록에 포함되기를 원하십니까? 자세히 알아보고 가입하세요!

봉사 프로그램 및 단일 작업

위의 권장 소프트웨어 프로젝트 외에도 작업할 프로젝트 또는 작업을 선택하는 더 많은 방법이 있습니다:

Logo 봉사 프로그램

Wikimedia는 Google Summer of Code 및 Outreachy와 같은 프로그램에서 인턴십을 제공합니다.

Logo 좋은 첫 번째 작업

신규 사용자에게 적합한 많은 단일 작업(많은 소프트웨어 프로젝트에 걸쳐)이 있습니다.
그러나 여기서 더 많은 작업을 수행할 수 있습니다. 멘토를 사용할 수 있거나 제안된 패치가 빠른 검토를 받을 것이라고 보장할 수 없습니다.

추가 리소스를 찾고 계십니까?

다른 것을 기여하고 싶습니까?

  • 기부 방법은 비기술적 영역에서도 더 많은 기여 방법을 나열합니다.

몇 가지 일반적인 커뮤니케이션 팁

  • Do your research first: When you decide to work on a task, you are expected to do some basic research yourself first: Look at the code, try to get some understanding what it is supposed to do, read related documentation, try to find the probable place(s) where you need to make code changes. For a general overview, please read the Basics to know.
    • In a 파브리케이터 task, see the project tags in the side bar to find out which code repository a task is about.
  • Ask and discuss in the best place:
    • In Phabricator tasks, discuss only specific questions about the topic of that very Phabricator task. General technical questions (e.g. how to set up a development environment or problems with Gerrit) are off-topic in Phabricator tasks.
    • For general technical questions, ask the broader Wikimedia community and use generic channels like IRC chat or mailing lists. (If you take part in an outreach program, then you can also use Zulip's technical-support stream.)
    • If you take part in an outreach program, then Zulip is for discussing questions about the outreach programs themselves.
  • Ask good questions: "Can you give me more info?", "Please guide me", "Please tell me how to start" are not good comments to start with: The more specific your questions are, the more likely somebody can answer them quickly. If you have no idea at all how to fix the bug, maybe that bug is not (yet) for you – consider finding an easier one first.
  • Provide context: When asking, explain what you want to achieve, and what you have tried and found out already, so others can help at the right level. Be specific – for example, copy and paste your commands and their output (if not too long) instead of paraphrasing in your own words. This avoids misunderstandings. Use specific titles and subject lines ("Proposal draft" or "Need help" is not specific).
  • Use inclusive language : Don't assume anyone's gender identity ("guys", "madam", "sir"). Use the name of the person instead.
  • Ask in public: Do not send private messages if your conversation topic is not secret. Private messages do not help others.
  • Be patient when seeking input and comments, especially during weekends and holidays.
    • On IRC, don't ask to ask, just ask: most questions can be answered by other community members too if you ask on an IRC channel. If nobody answers, please try again at a different time; don't just give up.
    • Do not ask people immediately for code review in a separate message. People receive Gerrit and Phabricator notifications.
  • Keep conversations readable: When you reply in Zulip, in Phabricator tasks, or on mailing lists, please avoid unneeded quoting of a complete previous comment. Provide sufficient context and keep threads readable.
  • Follow the code of conduct for Wikimedia technical spaces.
  • When you plan to work on a Phabricator task:
    • No need to ask for permission: Usually there is no reason to ask if you can work on something or if somebody could assign a task to you. There is no authority who assigns tasks or who needs to be asked first.
    • You do not need to announce your plans before you start working on a task but it would be welcome. At the latest when you are close to proposing a patch for a task, it is good to announce that you are working on it, so that others don't duplicate work: If nobody else is already assigned, set yourself as task assignee by using the Add Action… → Assign/Claim dropdown.
    • Tasks with existing patches:
      • If a task already has a recent patch in Gerrit, choose a different task to work on instead – avoid duplicating work.
      • If an existing patch in Gerrit has not been merged and has not seen any changes for a long time, you could also improve that existing patch, based on the feedback in Gerrit and in the task.
    • When your plans or interests change: If you don't work on a task anymore, please remove yourself as the assignee of the task, so others know that they can work on the task and don't expect you to still work on it.

By communicating clearly and early you get attention, feedback and help from community members.