{"title":"チケットをトリアージする","version":"6.1","locale":"ja","docname":"internals/contributing/triaging-tickets","url":"/ja/6.1/internals/contributing/triaging-tickets/","canonical":"https://djangodocs.dev/ja/6.1/internals/contributing/triaging-tickets/","summary":"Django uses Trac for managing the work on the code base. Trac is a community-tended garden of the bugs people have found and the features Django has decided…","html":"

チケットをトリアージするLink to this heading#

\n

Django uses Trac for managing the work on the code base. Trac is a\ncommunity-tended garden of the bugs people have found and the features Django\nhas decided to add. As in any garden, sometimes there are weeds to be pulled\nand sometimes there are flowers and vegetables that need picking. We need your\nhelp to sort out one from the other, and in the end, we all benefit together.

\n

他のガーデン同様に、我々も完璧を目指しますが、ケーキを持って食べることもできません。どんな綺麗な庭にも虫がいます。コミュニティーには、-- 善意での悪事 --をしてしまった良き人もいます。コミュニティーが自己管理し、問題を最小限に留め、新たの加入者にイロハを教えるのはコミュニティー全体の責務。

\n

我々はTracをDjangoの成果を完璧に表現することを目指しますが、限界の存在を理解しています。コミュニティーへTracのメンテナンスを分布する度、間違いが生じることを許容します。何らかの間違いが生じることは想定内なので、Tracは「ほぼ正確」です。間違ってなんぼ、我々は期限を守ってからの完璧主義です。

\n

We rely on the community to keep participating, keep tickets as accurate as\npossible, and raise issues for discussion on the Django Forum when there is\nconfusion or disagreement.

\n

Djangoはコミュニティプロジェクトであり、すべての貢献が役立ちます。 あなた なしではこれを実現することはできません！

\n
\n

トリアージのワークフローLink to this heading#

\n

Unfortunately, not all reports in the ticket tracker provide all the\nrequired details. A number of tickets have proposed\nsolutions, but those don't necessarily meet all the requirements adhering\nto the guidelines for contributing.

\n

One way to help out is to triage tickets that have been created by other\nusers.

\n

Most of the workflow is based around the concept of a ticket's\ntriage stages. Each stage describes where in its\nlifetime a given ticket is at any time. Along with a handful of flags, this\nattribute easily tells us what and who each ticket is waiting on.

\n

Since a picture is worth a thousand words, let's start there:

\n\"Django\n

We have four roles in this diagram. Maintainers (also known as Fellows) usually\ntake part in all of them, but anyone in the Django community can participate in\nany role except merger. The merger role is granted by a\nvote of the Steering Council.

\n\n\n

For example, here's the typical lifecycle of a ticket:

\n\n

Some tickets move through these steps quickly, while others take more time and\ndiscussion. Each contribution helps Django improve.

\n
\n
\n

トリアージのステージLink to this heading#

\n

Below we describe in more detail the various stages that a ticket may flow\nthrough during its lifetime.

\n
\n

Unreviewed (未レビュー)Link to this heading#

\n

The ticket has not been reviewed by anyone who felt qualified to make a\njudgment about whether the ticket contained a valid issue or ought to be closed\nfor any reasons. Unreviewed tickets appear in the "triage" queue.

\n

Unreviewed tickets may receive additional refinement before being accepted.\nUnless you are both the author of the ticket and intending to submit a patch,\nunreviewed tickets should not be claimed.

\n
\n
\n

Accepted (アクセプト)Link to this heading#

\n

The absolute meaning of "accepted" is that the issue described in the ticket is\nvalid and actionable. It is broken out into three queues:

\n\n
\n
\n

Ready For CheckinLink to this heading#

\n

The ticket was reviewed by any member of the community other than the person\nwho supplied the patch and found to meet all the requirements for a\ncommit-ready contribution. A merger now needs to give\na final review prior to being committed.

\n

There are a lot of pull requests. It can take a while for your patch to get\nreviewed. See the contributing code FAQ for some\nideas here.

\n
\n
\n

Someday/MaybeLink to this heading#

\n

This stage isn't shown on the diagram. It's used sparingly to keep track of\nlong-term changes.

\n

These tickets are uncommon and overall less useful since they don't describe\nconcrete actionable issues.

\n
\n
\n
\n

その他のトリアージ属性Link to this heading#

\n

A number of flags, appearing as checkboxes in Trac, can be set on a ticket:

\n
\n

Has patch (パッチあり)Link to this heading#

\n

This means the ticket has an associated solution. These will be reviewed to\nensure they adhere to the documented guidelines.

\n

The following three fields (Needs documentation, Needs tests,\nPatch needs improvement) apply only if a patch has been supplied.

\n
\n
\n

Needs documentation (ドキュメンテーションが必要)Link to this heading#

\n

This flag is used for tickets with patches that need associated\ndocumentation. Complete documentation of features is a prerequisite\nbefore we can check them into the codebase.

\n
\n
\n

Needs tests (テストが必要)Link to this heading#

\n

This flags the patch as needing associated unit tests. Again, this\nis a required part of a valid contribution.

\n
\n
\n

Patch needs improvement (パッチの改善が必要)Link to this heading#

\n

This flag means that although the ticket has a solution, it's not quite\nready for checkin. This could mean the patch no longer applies\ncleanly, there is a flaw in the implementation, or that the code\ndoesn't meet our standards.

\n
\n
\n

Easy pickings (簡単に取り組める)Link to this heading#

\n

Tickets that would require small, easy, changes.

\n
\n
\n

Type (タイプ)Link to this heading#

\n

チケットは以下のいずれかの タイプ に分類する必要があります。

\n\n
\n
\n

Component (コンポーネント)Link to this heading#

\n

Tickets should be classified into components indicating which area of\nthe Django codebase they belong to. This makes tickets better organized and\neasier to find.

\n
\n
\n

Severity (重要度)Link to this heading#

\n

The severity attribute is used to identify blockers, that is, issues that\nshould get fixed before releasing the next version of Django. Typically those\nissues are bugs causing regressions from earlier versions or potentially\ncausing severe data losses. This attribute is quite rarely used and the vast\nmajority of tickets have a severity of "Normal".

\n
\n
\n

Version (バージョン)Link to this heading#

\n

The version attribute indicates the earliest version in which the bug was\nreproduced. During triage, this field can be updated, but there is no need to\nmake further updates when that version goes out of support. The field should\nnot be reset to "dev" to show the issue still exists: instead, the tested\ncommit hash can be noted in a comment.

\n
\n
\n

UI/UXLink to this heading#

\n

This flag is used for tickets that relate to User Interface and User\nExperiences questions. For example, this flag would be appropriate for\nuser-facing features in forms or the admin interface.

\n
\n
\n

CcLink to this heading#

\n

You may add your username or email address to this field to be notified when\nnew contributions are made to the ticket.

\n
\n
\n

Keywords (キーワード)Link to this heading#

\n

With this field you may label a ticket with multiple keywords. This can be\nuseful, for example, to group several tickets on the same theme. Keywords can\neither be comma or space separated. Keyword search finds the keyword string\nanywhere in the keywords. For example, clicking on a ticket with the keyword\n"form" will yield similar tickets tagged with keywords containing strings such\nas "formset", "modelformset", and "ManagementForm".

\n
\n
\n
\n

チケットを閉じるLink to this heading#

\n

When a ticket has completed its useful lifecycle, it's time for it to be\nclosed. Closing a ticket is a big responsibility, though. You have to be sure\nthat the issue is really resolved, and you need to keep in mind that the\nreporter of the ticket may not be happy to have their ticket closed (unless\nit's fixed!). If you're not certain about closing a ticket, leave a comment\nwith your thoughts instead.

\n

If you do close a ticket, you should always make sure of the following:

\n\n

チケットは、次のような複数の方法で解決できます。

\n\n

If you believe that the ticket was closed in error -- because you're\nstill having the issue, or it's popped up somewhere else, or the triagers have\nmade a mistake -- please reopen the ticket and provide further information.\nAgain, please do not reopen tickets that have been marked as "wontfix" or\n"needsnewfeatureprocess". For "wontfix" tickets, bring the issue to the\nDjango Forum instead. For "needsnewfeatureprocess" tickets, propose the\nfeature through the new features process.

\n
\n
\n

How can I help with development?Link to this heading#

\n

The development process is primarily driven by community members. Really,\nANYONE can help.

\n

参加するには、まず Trac 上でアカウントを作成します。アカウントを持っているけれどパスワードを忘れてしまった場合は、パスワードのリセットページ を使ってリセットできます。

\n

次に、以下の方法で助けることができます。

\n\n\n

ただし、チケットデータベースで作業するすべての一般コミュニティメンバーの人たちに対して、以下のことを必ずお願いしています。

\n\n
\n
\n

リグレッションの bisectLink to this heading#

\n

A regression is a bug that's present in some newer version of Django but not in\nan older one. An extremely helpful piece of information is the commit that\nintroduced the regression. Knowing the commit that caused the change in\nbehavior helps identify if the change was intentional or if it was an\ninadvertent side-effect. Here's how you can determine this.

\n

Begin by writing a regression test for Django's test suite for the issue. For\nexample, we'll pretend we're debugging a regression in migrations. After you've\nwritten the test and confirmed that it fails on the latest main branch, put it\nin a separate file that you can run standalone. For our example, we'll pretend\nwe created tests/migrations/test_regression.py, which can be run with:

\n
Shell
$ ./runtests.py migrations.test_regression\n
\n

Next, we mark the current point in history as being "bad" since the test fails:

\n
Shell
$ git bisect bad\nYou need to start by "git bisect start"\nDo you want me to do it for you [Y/n]? y\n
\n

Now, we need to find a point in git history before the regression was\nintroduced (i.e. a point where the test passes). Use something like\ngit checkout HEAD~100 to check out an earlier revision (100 commits\nearlier, in this case). Check if the test fails. If so, mark that point as\n"bad" (git bisect bad), then check out an earlier revision and recheck.\nOnce you find a revision where your test passes, mark it as "good":

\n
Shell
$ git bisect good\nBisecting: X revisions left to test after this (roughly Y steps)\n...\n
\n

Now we're ready for the fun part: using git bisect run to automate the rest\nof the process:

\n
Shell
$ git bisect run tests/runtests.py migrations.test_regression\n
\n

You should see git bisect use a binary search to automatically checkout\nrevisions between the good and bad commits until it finds the first "bad"\ncommit where the test fails.

\n

Now, report your results on the Trac ticket, and please include the regression\ntest as an attachment. When someone writes a fix for the bug, they'll already\nhave your test as a starting point.

\n
\n
\n

Reviewing patchesLink to this heading#

\n

A great way to learn the Django codebase is to help review patches. It allows\nyou to focus on a fixed scope of Django with a particular perspective. Plus,\nDjango tends to receive more patches than it can review which causes the\nreview queue to build up. Contributors can help Django tremendously by\nreviewing patches.

\n

The review queue is defined by tickets in Trac that are in the "Accepted"\nstate with the flag "has patch" set and the flags "patch needs improvement",\n"needs tests" and "needs documentation" unset. There is also a set of\nPull Requests in GitHub with the "no ticket" label that can be reviewed.

\n
\n

Code review processLink to this heading#

\n

The general process to reviewing a patch for Django is as follows:

\n
    \n

  1. Pick a patch to review. This can be from the review queue or the\nPull Requests in GitHub with the "no ticket" label. If you're new, pick\na specific component to stick with. Django is a big codebase, so it's best\nto contribute consistently with a narrow focus and grow it slowly.

    2. \n

  2. Pull the branch. See the プルリクエストの取り扱い, including the git\nalias to make checking out other pull requests easier.

    3. \n

  3. Check the tests. If the ticket is for a bug, there should be a regression\ntest. Confirm that the test fails if the change is reverted. Check that the\ntests are adequately covering the code and logic as well. See\nContribution checklist.

    4. \n

  4. Test in your own Django project. See 開発バージョンをインストールする\nfor how. Explore the user interface and user experience with the change.\nDoes it feel right? Can you break it? Another approach is to assume\neverything is wrong. Can you demonstrate to yourself that each piece is\ncorrect?

    5. \n

  5. Check the documentation. Is the documentation understandable? Does it\nprovide the information the reader needs at that moment? Does it read well?\nIs it consistent with the documentation before and after it? See\nドキュメントをローカルでビルドする.

    6. \n

  6. Are you happy with the patch? This is fairly subjective, but that's fine.\nYou should ask, does the approach make sense to you and is there another\nway to do it that's better? Also ask yourself, is the scope of the change\nappropriate? Are things named appropriately? Renaming things is slow and\nchallenging in Django, so we should try to get it right from the start.\nAre there backwards compatibility concerns? Lastly, are there any other\ngeneral concerns such as things that may worry you or that should be looked\ninto?

    7. \n

  7. Review your feedback. Before you submit your feedback, consider the\nfeedback you want to share. It takes courage to open a Pull Request, we\nshould be thoughtful and considerate of the leap the author has made. If\nthere are nitpicky or small suggestions, use GitHub's suggestion feature.\nIf the approach isn't what you expected, consider asking the author why\nbefore requesting several changes. Seek to understand their reasoning\nfirst.

    8. \n

  8. Submit feedback on GitHub and update flags, "patch needs improvement",\n"needs tests", and "needs documentation", as needed. This will move the\nticket to the "waiting for author" queue. If you have given a\nspecific type of code review, please indicate that on the Pull Request.

    9. \n
\n
\n
\n

Types of code reviewsLink to this heading#

\n

Not everyone will or should give the same type of code review. Having a diverse\nset of opinions and experiences helps Django be better. If you are providing a\nspecific review, please indicate that on the Pull Request in GitHub. Below\nare some of the types of code review you can perform:

\n\n
\n
","rootId":"triaging-tickets","toc":[{"title":"トリアージのワークフロー","anchor":"triage-workflow","children":[]},{"title":"トリアージのステージ","anchor":"triage-stages","children":[{"title":"Unreviewed (未レビュー)","anchor":"unreviewed","children":[]},{"title":"Accepted (アクセプト)","anchor":"accepted","children":[]},{"title":"Ready For Checkin","anchor":"ready-for-checkin","children":[]},{"title":"Someday/Maybe","anchor":"someday-maybe","children":[]}]},{"title":"その他のトリアージ属性","anchor":"other-triage-attributes","children":[{"title":"Has patch (パッチあり)","anchor":"has-patch","children":[]},{"title":"Needs documentation (ドキュメンテーションが必要)","anchor":"needs-documentation","children":[]},{"title":"Needs tests (テストが必要)","anchor":"needs-tests","children":[]},{"title":"Patch needs improvement (パッチの改善が必要)","anchor":"patch-needs-improvement","children":[]},{"title":"Easy pickings (簡単に取り組める)","anchor":"easy-pickings","children":[]},{"title":"Type (タイプ)","anchor":"type","children":[]},{"title":"Component (コンポーネント)","anchor":"component","children":[]},{"title":"Severity (重要度)","anchor":"severity","children":[]},{"title":"Version (バージョン)","anchor":"version","children":[]},{"title":"UI/UX","anchor":"ui-ux","children":[]},{"title":"Cc","anchor":"cc","children":[]},{"title":"Keywords (キーワード)","anchor":"keywords","children":[]}]},{"title":"チケットを閉じる","anchor":"closing-tickets","children":[]},{"title":"How can I help with development?","anchor":"how-can-i-help-with-development","children":[]},{"title":"リグレッションの bisect","anchor":"bisecting-a-regression","children":[]},{"title":"Reviewing patches","anchor":"reviewing-patches","children":[{"title":"Code review process","anchor":"code-review-process","children":[]},{"title":"Types of code reviews","anchor":"types-of-code-reviews","children":[]}]}],"breadcrumbs":[{"docname":"internals/index","title":"Django internals","url":"/ja/6.1/internals/"},{"docname":"internals/contributing/index","title":"Django へのコントリビュート","url":"/ja/6.1/internals/contributing/"}],"prev":{"docname":"internals/contributing/bugs-and-features","title":"バグレポートと機能のリクエスト","url":"/ja/6.1/internals/contributing/bugs-and-features/"},"next":{"docname":"internals/mailing-lists","title":"メーリングリストとフォーラム","url":"/ja/6.1/internals/mailing-lists/"},"formats":{"html":"/ja/6.1/internals/contributing/triaging-tickets/","markdown":"/ja/6.1/internals/contributing/triaging-tickets.md","json":"/ja/6.1/internals/contributing/triaging-tickets.json"},"source":"https://github.com/django/django/blob/stable/6.1.x/docs/internals/contributing/triaging-tickets.txt","official":"https://docs.djangoproject.com/ja/6.1/internals/contributing/triaging-tickets/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10","1.9"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}