Here are some frequently asked questions about how to do things inGitHub issues that you used to be able to do onbpo.
Before you ask your own question, make sure you readIssue trackerandTriaging an issue (specifically includingGitHub labels) as thosepages include a lot of introductory material.
There is a wonderfulbeginner guide to writing and formatting on GitHub.Highly recommended.
One pro-tip we can sell you right here is that if you want to pastesome longer log as a comment, attach a file instead (see how below).If you still insist on pasting it in your comment, do it like this:
<details><summary>This is the summary text, click me to expand</summary>Here goes the long, long text.It will be collapsed by default!</details>
Drag them into the comment field, wait until the file uploads, and GitHubwill automatically put a link to your file in your comment text.
Use Markdown links. If you link to the default GitHub path, the filewill link to the latest current version on the given branch.
You can get a permanent link to a given revision of a given file bypressing “y”.
Use theGitHub search syntax or the interactiveadvanced search formthat generates search queries for you.
Subscribe another person to the issue by tagging them in the comment with@username.
If you want to subscribe yourself to an issue, click the🔔 Subscribe button in the sidebar.
Similarly, if you were tagged by somebody else butdecided this issue is not for you, you might click the🔕 Unsubscribe button in the sidebar.
There is no exact equivalent of the “nosy list” feature, so to preservethis information during the transfer, we list the previous members ofthis list in the first message on the migrated issue.
Add a checkbox list like this in the issue description:
-[x]#739-[]https://github.com/octo-org/octo-repo/issues/740-[]Adddelighttotheexperiencewhenalltasksarecomplete:tada:
then those will become sub-tasks on the given issue. Moreover, GitHub willautomatically mark a task as complete if the other referenced issue isclosed. More details in theofficial GitHub documentation.
For issues migrated to GitHub frombpo where the authors or commentersare not core developers, we opted not to link to their GitHub accountsdirectly. Users not in thepython organization on GitHub might not like comments toappear under their name from an automated import. Others never linked GitHub onbpo in the first place so linking their account, if any, would be impossible.
In those cases a “mannequin” account is present to help follow the conversationthat happened in the issue. In case the user did share their GitHub accountname in theirbpo profile, we use that. Otherwise, their classicbpousername is used instead.
Based on historical data we found it not being used very often.
Based on historical data we found those not being used very often.
This is not supported by GitHub.
We rarely updated this information and it turned out not to beparticularly useful outside of the change log.