Citation Rules
Citations
This document describes the implementation details of citing resources for the Northwestern University MS in Robotics program. It does not discuss when to cite works or which works to cite, citation rules can be found in the The NUMSR Honor Code.
Citation style is divided into categories, based on the work that is being done. These rules form a baseline, but may be superseded by assignment-specific requirements.
These rules must be followed strictly: even unintentional deviation from these rules may be viewed as evidence of academic integrity violations: it is your responsibility to seek clarification and understand and implement these rules.
Reports and Written Work (including Portfolios)
- For reports and other formal written work, the format used should follow The IEEE Reference Style Guide for Authors [1], with some additions and modifications noted below.
- At the end of the document, create a section called "References" and provide a list of references.
- Each item in the list is numbered, with the number placed in square brackets (e.g., [1], [2], etc.)
- To cite a reference inline, place the corresponding number near the text where it is required.
- To cite pages, a figure, or a section etc. within a work, do so like [1, Fig. 4], [2, pp. 45-48].
- The ordering of the citations in the reference list is not important for the purposes of the honor code: however, it may be important as part of proper formatting and style.
- When citing online resources, you should always include the date you accessed the resource.
- All direct quotations should be surrounded by quotation marks (
"
") and cited inline. - When citing a git repository or a file from a git repository, the citation should include the SHA1 hash of the commit that was used.
- If the repository is hosted on Github this requirement is satisfied by providing a link to the specific commit (which is obtainable by browsing the commit history on github).
- If hosted on Github, there is an option to get a permanent link to a file when browsing it (pressing
C-S-,
). - Other code hosting websites have similar features.
Citing Collaborators
- To cite fellow students with whom you have worked, and whose contributions do not require a inline citation, use the following format:
- [1] Worked With: Name 1, Name 2, etc.
- This line should be the first line in your references list, and you can add names to it as needed.
- It is sufficient to have a single line listing your general collaborators, even if you worked on different problems with different groups.
- If a project is specifically structured as a group project, then members of the group do not need to be cited: they shall be considered authors and acknowledged where authorship is acknowledged.
- The absence of a first reference stating who you worked with is a declaration that you did not work with anybody on the assignment.
- If a student or group of students makes a contribution that requires an inline citation, those students should be listed on a separate line,
using the format outlined in [1, Sec. Q], which looks like
Author1, Author2, private communication, Abbrev Month, year
Source Code
- All source code that you write should be in a
git
repository, and these guidelines assume that. - In the base directory of the git repository, create a file called
citations.txt
- The
citations.txt
contains your reference list. The format of the reference list is the same as that for a written report, with the following modifications:- Words that should be italicized are set between forward-slash (
/
) characters: (e.g.,/Title/
)
- Words that should be italicized are set between forward-slash (
- Each repository should contain a
README.md
file, that (minimally) lists the authors of the code.
Inline Code Citations
- Inline citations for code have extra requirements to ensure that it is clear where your work begins and another ends.
The following are the only acceptable formats for citing a portion of code inline.
- For
C++ or C
:
// ############################ Begin_Citation [4, file.cpp:123-456] ############################ Code that was influenced by the citation here // ############################ End_Citation [4] #############################
- For
Python
or other languages where#
is a comment:
############################### Begin_Citation [5] ############################ Code that was influenced by the citation here ############################### End_Citation [5] #############################
- For
xml
and similar languages:
<!--########################### Begin_Citation [6] #########################--> Code that was influenced by the citation here <!--########################### End_Citation [6] ##########################-->
- Other languages, should use their comment character.
- For
- The exact number of
#
characters is not important, but there should be at least 10 before and after the citation. - The start of the citation must say
Begin_Citation
and is case-sensitive. It must be followed by a valid reference number in square brackets - The end of the citation must say
Begin_Citation
and is case-sensitive. It must be followed by a valid reference number in square brackets - When the inline citation references source code that is part of a bigger project, the inline citation must include the filename and line numbers (e.g., [4, file.cpp:123-126]).
- The citation must indicate the file and lines that were used (e.g., [4, file.cpp:123-126]
- If the code was copied or adapted, the reader must be able to find the source of that code based solely on the information you provide.
- Failure to strictly follow these formatting requirements is an academic integrity violation, even if it appears as an attempt to provide a citation.
- If you look at a former solution (which is highly discouraged), it is the default assumption that there will be a direct link between what you looked at
and what you are going to be coding, even if code is not copied directly.
- The influence of that code (whether implicit or explicit) must be acknowledged with inline citations specifying specific files and line numbers.
- The absence of specific inline citations is an assertion that there is not literal, functional, or architectural (outside of the assignment specifications) influence of that solution on your code.
Inline Comment Citations
- Comments are treated like other written text for the purpose of inline citations.
- It can be very appropriate to provide inline citations in comments.
- For example, if you read a blog post that said "Algorithm X is good at Y", it is appropriate to place a comment
AI Tools
There are additional rules for AI tools (such as ChatGPT):
External AI Tool
- If your use of the AI tool is external to your text editor (e.g., you use a website) you must provide a transcript of the conversation in your git repository and refer to it in the citation.
- There must be a persistent and publicly accessible URL for each transcript:
- The URL may be hosted with the AI tool provider, so long as the URL is publicly accessible
- The transcript may be stored in a separate
git
repository with the purpose of hosting your cited AI chats - Transcripts may also be hosted within the same git repository as your code under an
ai_citations
directory.
- The format for citing an AI assistant is:
Model Name, ver X. Company Name. Used On: Date. Transcript Available: url to transcript
- Company name may be "Self-Hosted" if you are self-hosting the assistant.
- For long transcripts, the inline citation should include line numbers or other indicators of which section of the cited transcript provided the answer.
Internal AI Tool
- If your AI tool is tied into your text editor,
- Commit prior to using the tool.
- Use the tool and accept the results
- Commit after the results were accepted.
- The citation format is
Name of AI Tool. Comapny. Used on Date. Commit prior to use SHA1
- Basic code-completion tasks that do not introduce new logic into the system are exempt.
- Judgment is required here, but to meet the requirement, the generated code must not:
- Introduce any control-flow or branching statements.
- Implement any arithmetic or logical expressions.
- Call API functions that you have never heard of before.
- Judgment is required here, but to meet the requirement, the generated code must not:
Example
Here is an example citations.txt
:
Worked With: [List every person you worked with generally here.] [1] Github Copilot. Microsoft. Used on 9/21/2023. Commit prior to use is 3fd56754423456434233242. Commit after use is 4543123423423a [2] ChatGpt. OpenAIUsed on 9/22/2023. Transcript is in ./chatgpt/transcript1.txt [3] https://stackoverflow.com/the/answer Accessed on 9/23/22 [4] John Smith [if John Smith gave you a specific idea outside of generally working with you].
And here is an example of a C++ file that used a citation
#include<iostream> // ############################## Begin_Citation [2, transcript1.txt:450-500] ############################## int main() { std::cout << "Hello ROS!" << std::endl; return 0; } // ############################## End_Citation [2] ###############################
Group Projects
In group coding projects (and unless otherwise specified), each person should be assigned a letter (a-z
) an maintain their own citation numbering:
- All citations are suffixed with the letter of the person who added the citation (e.g.,
[1a]
). - Citation lists can be maintained separately as
citations_a.txt
for each person to avoid git conflicts. - The citation list should be combined into a single
citations.txt
at the end of the project.- The numbering does not need to be redone, letter suffixes can remain.
References
[1] IEEE Publication Operations. IEEE Reference Guide, V11.29.2023. 2023. Accessed: 9/5/2024 [Online]. Available https://journals.ieeeauthorcenter.ieee.org/wp-content/uploads/sites/7/IEEE_Reference_Guide.pdf