Rhea Sukthanker
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
      • Invitee
    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Versions and GitHub Sync Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
Invitee
Publish Note

Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

Your note will be visible on your profile and discoverable by anyone.
Your note is now live.
This note is visible on your profile and discoverable online.
Everyone on the web can find and read all notes of this public team.
See published notes
Unpublish note
Please check the box to agree to the Community Guidelines.
View profile
Engagement control
Commenting
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Suggest edit
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
Emoji Reply
Enable
Import from Dropbox Google Drive Gist Clipboard
   owned this note    owned this note      
Published Linked with GitHub
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
## 1. Introduction Both the ethical implications of the research published at the AutoML Conference as well as its accessibility to everyone are key concerns that should be addressed by authors and reviewers. The first part of these guidelines discusses how and why we review papers with regards to their real-world impact as well as provides guidance on how to integrate such discussions into the submissions themselves. Reviewers should base their ethics review on the criteria we present here. **This section is based on the [NeurIPS ethics guidelines](https://nips.cc/Conferences/2023/EthicsGuidelinesForReviewers)**. Furthermore, we expect authors to make their papers as accessible as possible so that both reviewers and readers can enjoy them to the fullest. Therefore we provide a list of accessibility measures that reviewers are encouraged to evaluate in the submitted papers and suggest improvements to. Beyond the submission, there is also information on how to create inclusive and accessible presentations and posters, so that the audience will have the best possible experience. **This section is based on the [ICML guidelines](https://icml.cc/Conferences/2023/AccessiblePapersAndTalks) for accessible and inclusive papers, talks and posters**. ## 2. The AutoML Conference Ethics Review Process As Machine Learning (ML) research and applications have increasing real-world impact, the likelihood of meaningful social benefit increases, as does the attendant risk of harm. Indeed, problems with data privacy, algorithmic bias, automation risk, and potential malicious uses of AI have been well-documented e.g. by [[Whittlestone et al. 2019](http://lcfi.ac.uk/media/uploads/files/AIES-19_paper_188_Whittlestone_Nyrup_Alexandrova_Cave.pdf)]. In the light of these findings, ML researchers can no longer assume that their research will have a net positive impact on the world [[Hecht et al., 2018](https://arxiv.org/pdf/2112.09544.pdf)]. The research community should consider not only the potential benefits but also the potential negative societial consequences of ML research, and adopt measures that enable positive trajectories to unfold while mitigating the risk of harm. Hence, we expect authors to discuss such ethical and societal consequences of their work in their papers, while avoiding excessive speculation. The AutoML Conference template provides a section for the broader impact statement. This document should be used by both authors and reviewers (including normal reviewers and ethics reviewers) in order to get on the same page about the AutoML Conference's ethics principles. The primary goal for reviewers should be to provide critical feedback for the authors to incorporate into their paper. We do not expect this feedback to be the deciding factor for acceptance in most cases, though papers could be rejected if substantial concerns are raised that the authors are not able to address adequately. There are two aspects of ethics we consider: potential negative societal impacts (Section 2.1) and general ethical conduct in research (Section 2.2). Both sections provide authors and reviewers with prompts to reflect on a submission’s possible harms. The broader impact statement of a paper does not need to answer these exact questions or all of them, but it should address both categories of ethics adequately. J. Whittlestone, R. Nyrup, A. Alexandrova, K. Dihal, and S. Cave. (2019) [Ethical and societal implications of algorithms, data, and artificial intelligence: a roadmap for research](https://nuffieldfoundation.org/sites/default/files/files/Ethical-and-Societal-Implications-of-Data-and-AI-report-Nuffield-Foundat.pdf). London: Nuffield Foundation. B. Hecht, L. Wilcox, J. P. Bigham, J. Schoning, E. Hoque, J. Ernst, Y. Bisk, L. De Russis, L. Yarosh, B. Anjam, D. Contractor, and C. Wu. (2018) [It’s Time to Do Something: Mitigating the Negative Impacts of Computing Through a Change to the Peer Review Process](https://brenthecht.com/papers/FCADIscussions_NegativeImpactsPost_032918.pdf). ACM Future of Computing Blog. ### 2.1 Potential Negative Societal Impacts Submissions to the AutoML Conference are expected to include a discussion about potential negative societal implications of the proposed research artifact or application. (This corresponds to question 1c of the [Reproducibility Checklist](https://github.com/automl-conf/LatexTemplate/blob/main/instructions.pdf)). Whenever these are identified, submissions should also include a discussion about how these risks can be mitigated. Grappling with ethics is a difficult problem for the field, and thinking about ethics is still relatively new to many authors. Given its controversial nature, we choose to place a strong emphasis on transparency. In certain cases, it will not be possible to draw a bright line between ethical and unethical. A paper should therefore discuss any potential issues, welcoming a broader discussion that engages the whole community. A common difficulty with assessing ethical impact is its indirectness: most papers focus on general-purpose methodologies (e.g., face-recognition methodologies), whereas ethical concerns are more apparent when considering deployed applications (e.g., surveillance systems). Also, real-world impact (both positive and negative) often emerges from the cumulative progress of many papers, so it is difficult to attribute the impact to an individual paper. The ethics consequences of a paper can stem from either the methodology or the application. On the methodology side, for example, a new adversarial attack might give unbalanced power to malicious entities; in this case, defenses and other mitigation strategies would be expected, as is standard in computer security. On the application side, in some cases, the choice of application is incidental to the core contribution of the paper, and a potentially harmful application should be swapped out (as an extreme example, replacing ethnicity classification with bird classification), but the potential mis-uses should be still noted. In other cases, the core contribution might be inseparable from a questionable application (e.g., reconstructing a face given speech). In such cases, one should critically examine whether the scientific (and ethical) merits really outweigh the potential ethical harms. A non-exhaustive list of potential negative societal impacts is included below. Consider whether the proposed methods and applications can: 1. Directly facilitate injury to living beings. For example: could it be integrated into weapons or weapon systems? 2. Raise safety or security concerns. For example: is there a risk that applications could cause serious accidents or open security vulnerabilities when deployed in real-world environments? 3. Raise human rights concerns. For example: could the technology be used to discriminate, exclude, or otherwise negatively impact people, including impacts on the provision of vital services, such as healthcare and education, or limit access to opportunities like employment? Please consult the [Toronto Declaration](https://www.torontodeclaration.org/declaration-text/english/) for further details. 4. Have a detrimental effect on people’s livelihood or economic security. For example: Have a detrimental effect on people’s autonomy, dignity, or [privacy](https://www.atlantis-press.com/article/125975552.pdf) at work, or threaten their economic security (e.g., via automation or disrupting an industry)? Could it be used to increase worker surveillance, or impose conditions that present a risk to the health and safety of employees? 5. Develop or extend harmful forms of surveillance. For example: could it be used to collect or analyze bulk surveillance data to predict immigration status or other protected categories, or be used in any kind of criminal profiling? 6. Severely damage the environment. For example: would the application incentivize significant environmental harms such as deforestation, fossil fuel extraction, or pollution? 7. Deceive people in ways that cause harm. For example: could the approach be used to facilitate deceptive interactions that would cause harms such as theft, fraud, or harassment? Could it be used to [impersonate public figures](https://www.politico.com/newsletters/digital-future-daily/2023/09/26/your-friend-ai-00118222) to influence political processes, or as a tool of hate speech or abuse? ### 2.2 General Ethical Conduct in Research Submissions must adhere to ethical standards for responsible research practice and due diligence in the conduct. If the research uses human-derived data, consider whether that data might: 1. Contain any personally identifiable information or sensitive personally identifiable information. For instance, does the dataset use features or label information about individual names? Did people provide their consent on the collection of such data? Could the use of the data be degrading or embarrassing for some people? 2. Contain information that could be deduced about individuals that they have not consented to share. For instance, a dataset for recommender systems could inadvertently disclose user information such as their name, depending on the features provided. 3. Encode, contain, or potentially exacerbate bias against people of a certain gender, race, sexuality, age, nationality or who have other protected characteristics. For instance, does the dataset represent the diversity of the community where the approach is intended to be deployed? Does the dataset implicitly encode protected attributes through an individual's residential address, languages spoken, occupation etc? 4. Contain human subject experimentation and whether it has been reviewed and approved by a relevant oversight board. For instance, studies predicting characteristics (e.g., health status) from human data (e.g., contacts with people infected by COVID-19) are expected to have their studies reviewed by an ethical board. 5. Have been discredited by the creators. For instance, the DukeMTMC-ReID dataset has been taken down and it should not be used in AutoML Conference submissions. Similarly the following datsets are deprecated by their creators: - Full version of LAION-5B - Versions of ImageNet 21k from prior to Dec 2019 - 80 Million Tiny Images - MS-Celeb-IM - eDuke MTMC - Brainwash - MegaFace - HRT-Transgender In general, there are other issues related to data that are worthy of consideration and review. These include: 1. Consent to use or share the data. Explain whether you have asked the data owner’s permission to use or share data and what the outcome was. Even if you did not receive consent, explain why this might be appropriate from an ethical standpoint. For instance, if the data was collected from a public forum, were its users asked consent to use the data they produced, and if not, why? 2. Domain specific considerations when working with high-risk groups. For example, if the research involves work with minors or vulnerable adults, have the relevant safeguards been put in place? 3. Filtering of offensive content. For instance, when collecting a dataset, how are the authors filtering offensive content such as racist language or violent imagery? 4. Compliance with [GDPR](https://gdpr-info.eu/) and other data-related regulations. For instance, if the authors collect human-derived data, what is the mechanism to guarantee individuals’ right to be forgotten (removed from the dataset)? This list is not intended to be exhaustive — it is included here as a prompt for author and reviewer reflection. ## 3. Accessibility & Inclusivity at the AutoML Conference We want to make the AutoML Conference a space for discussing AutoML research everyone can participate in. This does not only include physical attendance, but also the ability to fully understand and enjoy the papers, talks and presentations at the conference. For authors, this is usually not a large time commitment, but enables both readers and reviewers to get the most out of submissions. Reviewers are encouraged to review papers with accessibility in mind and provide suggestions for improvement in their review. We do not expect questions of accessibility to meaningfully influence the review score, especially since they should be easy to improve upon, but rather see this as feedback for improving the general readability of the paper. Section 3.1 contains a list of accessibility information for papers and Section 3.4 the same for talks and posters. We also provide guidance on inclusive language and encourage authors to consider their papers and presentations compared to what is proposed in Section 3.3. These are, of course, not hard rules, but our goal is to foster a welcoming community and all participants can help us achieve this goal by being inclusive in their language. Section 3.2 contains our guidelines on citations and name changes. Making sure the name cited in a submission is correct is an important task of the authors and they are expected to fix any mistakes raised immediately. ### 3.1 Paper Accessibility Having an accessible paper means that your work can be reviewed by all of our reviewers and enjoyed by the broadest possible audience, including disabled and neurodivergent people. Please follow the guidelines below to assure your paper is accessible. As mentioned above, for this part of the guidelines we follow ICML’s process. ICML has developed these guidelines in collaboration with the NAACL 2022 team, and the [NAACL 2022 blog post](https://2022.naacl.org/blog/publication-accessibility-quality-inclusivity/) contains additional details and resources. 1. Create figures that are high contrast and high resolution, so they remain clear when zooming in. 2. Ensure that fonts are sufficiently large, especially in figures. The font size in figures should be no smaller than the font size of the caption of the figure. 3. Ensure that your visuals are legible to people with all types of color vision by following the recommendations of [How to Design for Color Blindness](https://www.getfeedback.com/resources/ux/how-to-design-for-color-blindness/) and [Color Universal Design](https://www.getfeedback.com/resources/ux/how-to-design-for-color-blindness/): - Choose color schemes that can be easily identified by people with all types of color vision, in consideration with the actual lighting conditions and usage environment. Many plotting tools include specific settings for this. - Do not rely on color to convey information, but also use a combination of different shapes, positions, line types, and coloring patterns. 4. Ensure that the PDF of your paper is accessible by following the steps in the [SIGACCESS Accessible PDF Author Guide](http://www.sigaccess.org/welcome-to-sigaccess/resources/accessible-pdf-author-guide/). This means in particular: - Check that all fonts are embedded in the PDF. - Set the title and language for the PDF. - Add tags to the PDF. Tags capture the underlying logical structure, reading order, etc. and allow the use of assistive technologies such as [screen readers](https://en.wikipedia.org/wiki/Screen_reader). - Add alternative text to all figures, tables, charts, images, diagrams, and other visuals in your paper. This is what will be spoken to readers who cannot see the visuals. Use plain, concise language that captures both the content and the function of the visuals in the paper. Highlight the aspects of the visuals that are salient to the paper, rather than merely describing the visuals or repeating their captions. Follow the [SIGACCESS guidelines](https://www.sigaccess.org/welcome-to-sigaccess/resources/describing-figures/), which include several examples. For further examples see Appendix F of [2kenize: Tying Subword Sequences for Chinese Script Conversion](https://arxiv.org/pdf/2005.03375.pdf). 5. Set the tab order for the PDF. 6. Mark table headers in the PDF. ### 3.2 Author Names and Citations in Submissions Many authors (in particular, transgender, non-binary, and/or gender-diverse authors; married and/or divorced authors; etc.) can change their names during their academic careers. You show respect to the authors that you cite by using their updated names. Not using their updated names produces ongoing harms, such as a [violation of privacy, denial of credit, denial of dignity, ongoing corrective epistemic labor, epistemic exploitation, and exposure to abuse and trauma, and can even constitute hate speech](https://publicationethics.org/news/vision-more-trans-inclusive-publishing-world). Please take the following steps: 1. Ensure that you are using updated author names by checking their website or Semantic Scholar page. 2. To obtain bibliographic entries, do not rely on platforms such as Google Scholar that [do not properly support author name changes](https://scholar.hasfailed.us/). We instead recommend using [dblp](https://dblp.org/). 3. Use tools such as [Rebiber](https://github.com/yuchenlin/rebiber) and manually check your work to spot and fix outdated bibliographic entries and in-text citations. 4. For works that include examples from citation networks, academic graphs, etc., manually check that none of the examples contain incorrect names, which can occur in publicly available academic graphs. It is critical that you follow the above steps in all drafts of your paper, not just in the camera-ready version. Any version of your paper that you upload to arXiv or submit for open review can be indexed or scraped, and if it contains incorrect names, it can result in the harm mentioned above. If you discover or are notified that any of your papers contain incorrect names, make the appropriate corrections immediately. ### 3.3 Inclusive Language Use inclusive and respectful language throughout your paper: 1. Use examples that are understandable and respectful to a diverse and multicultural audience. It is acceptable to include offensive content when it is relevant to the focus of your paper (e.g., to provide [examples of toxic data](https://arxiv.org/pdf/2006.16923.pdf)). In this case, we recommend including a trigger or content warning at the beginning of your paper (for an example, see [Harms of Gender Exclusivity and Challenges in Non-Binary Representation in Language Technologies](https://arxiv.org/pdf/2108.12084.pdf)). 2. When talking about people and their individual characteristics including age, caste, disability, gender, neurodivergence, racial and ethnic identity, religion, sexual orientation, socioeconomic status, etc. follow the [APA style guide](https://apastyle.apa.org/style-grammar-guidelines/bias-free-language). 3. If your paper discusses accessibility issues or refers to people with disabilities, please follow the [SIGACCESS Accessible Writing Guide](https://www.sigaccess.org/welcome-to-sigaccess/resources/accessible-writing-guide/). 4. Avoid inherently sexist language, such as generic “he” and gendered professional titles (e.g., use “firefighter” instead of “fireman”). Also, avoid using combinations such as “he or she,” “she or he,” “he/she,” and “(s)he” as alternatives to the [singular “they”](https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they) because such constructions imply an exclusively binary nature of gender and exclude individuals who do not use these pronouns. See [RECSYS guidelines](https://recsys.acm.org/recsys19/presentation-guidelines/) for additional recommendations. 5. Consider adding your pronouns (if comfortable) under your name in the camera-ready version to ensure that you and your co-authors are referred to appropriately when your paper is discussed. This practice additionally normalizes pronouns, which creates a more welcoming environment for trans, non-binary, and/or gender-diverse folks. For an example, see [Harms of Gender Exclusivity and Challenges in Non-Binary Representation in Language Technologies](https://arxiv.org/pdf/2108.12084.pdf). If you are not familiar with pronouns, see the [oSTEM guide to pronouns](https://ostem.blob.core.windows.net/webfiles/Resources/ostem_PronounGuide_PrinterPaper.pdf). ### 3.4 Talks and Posters There are many great guides to making accessible and inclusive talks and posters; we advise everyone to consider all the points made in the [RECSYS guidelines](https://recsys.acm.org/recsys19/presentation-guidelines/), the [ACM guide](https://dl.acm.org/doi/10.1145/3085564), and the [W3C guide](https://www.w3.org/WAI/teach-advocate/accessible-presentations/). In particular, we would like to highlight the following items: 1. Keep your slides and posters clear, simple, and uncrowded. Use large, sans-serif fonts, with ample white space between sentences and paragraphs. Use bold for emphasis (instead of italics, underline, or capitalization), and avoid special text effects (e.g., shadows). 2. Choose high contrast colors; dark text on a cream background works best. 3. Avoid flashing text or graphics. For any graphics, add a brief text description of the graphic right next to it. 4. Choose color schemes that can be easily identified by people with all types of color vision and do not rely on color to convey a message (see [How to Design for Color Blindness](https://www.getfeedback.com/resources/ux/how-to-design-for-color-blindness/https://www.getfeedback.com/resources/ux/how-to-design-for-color-blindness/) and [Color Universal Design](https://jfly.uni-koeln.de/color/) for further details). 5. Use examples that are understandable and respectful to a diverse, multicultural audience. 6. When beginning a talk, introduce yourself with your chosen name and pronouns (if comfortable), and describe your appearance and background so that blind and visually impaired individuals can picture the talk. Every time you start talking after another person was just talking, say “This is [insert your name],” so that blind and visually impaired folks can easily know who is talking. 7. When welcoming, referring to or interacting with your audience: - Do not use: ladies and gentlemen, boys and girls, men and women, brothers and sisters, he or she, sir/madam. - Instead, use: esteemed guests, that person, friends and colleagues, students, siblings, everyone, the participants. - Do not assume the pronouns of any audience member, or publicly ask audience members for their pronouns. Instead, use [singular “they”](https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they) to refer to audience members. 8. Avoid inherently sexist language, such as generic “he” and gendered professional titles (e.g., use “firefighter” instead of “fireman”). Also, avoid using combinations such as “he or she,” “she or he,” “he/she,” and “(s)he” as alternatives to the [singular “they”](https://apastyle.apa.org/style-grammar-guidelines/grammar/singular-they) because such constructions imply an exclusively binary nature of gender and exclude individuals who do not use these pronouns. See [RECSYS guidelines](https://recsys.acm.org/recsys19/presentation-guidelines/) for additional recommendations. 9. Avoid intentional and casual ableist language, such as “Oh, I’m dumb!”, “I’m blind”, “Are you deaf?”, “I’m so OCD about these things”, “I hope everyone can see this”, etc. This language alienates and harms disabled and neurodivergent people. 10. When speaking, do not assume that all audience members can see the slides: cover everything important in what you say, even if it’s already on the slide. Be kind when asked to say content on your slides (especially equations) out loud. 11. Before responding to an audience question, slowly repeat the question so that everyone can catch and process the question. When speaking, repeat important words and ideas to allow everyone to follow along. 12. For virtual talks and poster sessions, monitor the chat for questions.

Import from clipboard

Paste your markdown or webpage here...

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lose their connection.

Create a note from template

Create a note from template

Oops...
This template has been removed or transferred.
Upgrade
All
  • All
  • Team
No template.

Create a template

Upgrade

Delete template

Do you really want to delete this template?
Turn this template into a regular note and keep its content, versions, and comments.

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Help & Tutorial

How to use Book mode

Slide Example

API Docs

Edit in VSCode

Install browser extension

Contacts

Feedback

Discord

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions and GitHub Sync
Get Full History Access

  • Edit version name
  • Delete

revision author avatar     named on  

More Less

Note content is identical to the latest version.
Compare
    Choose a version
    No search result
    Version not found
Sign in to link this note to GitHub
Learn more
This note is not linked with GitHub
 

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub
      • Please sign in to GitHub and install the HackMD app on your GitHub repo.
      • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
      Learn more  Sign in to GitHub

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Include title and tags
      Available push count

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully