•  


페이지를 파싱하기 어렵습니다. Pull Request Guidelines ? Creative Commons Open Source

Pull Request Guidelines

We ask that contributors to CC projects submit a pull request with your changes. If you're not familiar with pull requests, please read this GitHub documentation . Here are our expectations for pull requests; following them will expedite the process of merging your code in.

Read and follow the contributing guidelines and code of conduct for the project. Here are screenshots of where to find them for first time contributors and previous contributors .

We aim to review pull requests within five business days. * . If it has been over five business days and you have not received any feedback, feel free to follow up with us.

  • Make A Branch
    • Please create a separate branch for each issue that you're working on. Do not make changes to the default branch (e.g. master , develop ) of your fork.
  • Push Your Code ASAP
  • Describe Your Pull Request
    • Use the format specified in pull request template for the repository. Populate the stencil completely for maximum verbosity.
      • Tag the actual issue number by replacing #[issue_number] e.g. #42 . This closes the issue when your PR is merged.
      • Tag the actual issue author by replacing @[author] e.g. @issue_author . This brings the reporter of the issue into the conversation.
      • Mark the tasks off your checklist by adding an x in the [ ] e.g. [x] . This checks off the boxes in your to-do list. The more boxes you check, the better.
    • Describe your change in detail. Too much detail is better than too little.
    • Describe how you tested your change.
    • Check the Preview tab to make sure the Markdown is correctly rendered and that all tags and references are linked. If not, go back and edit the Markdown.
      Screenshot: Populated pull request
  • Request Review
    • Once your PR is ready, remove the "[WIP]" from the title and/or change it from a draft PR to a regular PR.
    • If a specific reviewer is not assigned automatically, please request a review from the project maintainer and any other interested parties manually.
  • Incorporating feedback

Code guidelines

  • Write comprehensive and robust tests that cover the changes you've made in your work.
  • Follow the appropriate code style standards for the language and framework you're using (e.g. PEP 8 for Python).
  • Write readable code ? keep functions small and modular and name variables descriptively.
  • Document your code thoroughly.
  • Make sure all the existing tests pass.
  • User-facing code should support the following browsers:
    • Chrome (Webkit-Blink / 22+)
    • Firefox (Gecko / 28+)
    • Edge (Chromium based / 12+)
    • Opera (Chromium-Blink / 12.1+)
    • Safari (Apple’s Webkit / 7+)
    • IE 11 (Trident)

* CC staff work Monday through Friday and are not available on weekends and national holidays (the specific holidays observed vary based on the person's location). CC is closed between Christmas Eve and New Years' Day every year and for a few days following the CC Global Summit. Also, our availability during events such as the CC Global Summit and our biannual staff meetups is limited.

- "漢字路" 한글한자자동변환 서비스는 교육부 고전문헌국역지원사업의 지원으로 구축되었습니다.
- "漢字路" 한글한자자동변환 서비스는 전통문화연구회 "울산대학교한국어처리연구실 옥철영(IT융합전공)교수팀"에서 개발한 한글한자자동변환기를 바탕하여 지속적으로 공동 연구 개발하고 있는 서비스입니다.
- 현재 고유명사(인명, 지명등)을 비롯한 여러 변환오류가 있으며 이를 해결하고자 많은 연구 개발을 진행하고자 하고 있습니다. 이를 인지하시고 다른 곳에서 인용시 한자 변환 결과를 한번 더 검토하시고 사용해 주시기 바랍니다.
- 변환오류 및 건의,문의사항은 juntong@juntong.or.kr로 메일로 보내주시면 감사하겠습니다. .
Copyright ⓒ 2020 By '전통문화연구회(傳統文化硏究會)' All Rights reserved.
 한국   대만   중국   일본