So your teacher wants you to do open source
If your teacher (or tutorial/video/hackathon/etc) says "go do X in an open source project" and then sends you off unsupervised, they haven't adequately prepared you to be a contributor, or thought through the consequences of their assignment. Don't do it.
These teachers often have good intentions. They know projects need contributors. Open source projects can be high quality examples of how to structure and run larger/more complex code than a class can produce. They want their students to gain experience and help projects. However, they don't seem to know how to actually prepare their students to do this successfully. It tends to manifest in a few common types of interactions that aren't ultimately helpful and don't produce long lasting contributors.
Open source maintainers don't like dealing with these types of interactions. They don't have the time and mental energy to keep telling each person that comes by why it wasn't helpful. To each student it's a single assignment, but to each maintainer it's a relentless stream. It takes away from the limited resources they have to dedicate to do the actual things the project needs. We're happy to help interested new contributors, but don't start your open source journey with a bad impression.
Here are some of the types of interactions I deal with on a regular basis, and why they're not helpful.
Learning to use Git/GitHub
Flask regularly gets PRs with a title like "Making a Change" or "Added a File". The assignment was clearly to learn how Git branching, commits, and GitHub PRs work. But instead of doing this in their own repository, they did it to a large public repository. The teacher may have told them to look at Flask earlier as an example, or to fork it and work on the fork only. But it resulted in a useless PR that notified every single person subscribed to the repository. And from the outside, not knowing it's an assignment, it looks like a random user trying to get their name into a popular project.
Linters, Formatters, and Other Tools
The student is learning about code and project quality tools, such as flake8, black, etc. They picked a tool, ran it with its default configuration, and submitted all the changes it made. "Improving Code Quality" is a common title for this PR. Except they forgot to check (or hadn't learned how to check) if a project is already using some tools, or different configurations for the tools.
Most maintainers, especially of popular projects, are well aware of the different code quality tools out there, and either already set them up or deliberately don't want to use them. These tools can end up changing almost every line of every file in a project, something no maintainer would want to or even be able to review from a random first time contributor.
Another form of this is running some generic security tool and just pasting its output as an issue. If you're going to report a security issue, first don't do it publicly, and second be sure you actually understand what you're reporting and if it's even applicable.
A new form of this is "AI" (LLM) tools that claim to be able to improve something like documentation, tests, or performance, or identify security issues. These ones are good at making a report look "right" so it takes even more effort for maintainers to finally realize it's nothing.
Studies and Surveys
"My team at ABC University is doing a study about XYZ in open source. We somehow got your email, please fill out this survey." These emails are so annoying. First, how did you get my email, and how did your university possibly approve of using it in this way. Second, you're the 100th group to do a study about open source, and yet it seems that nothing has changed since the 1st group. Where are all the study results? Why hasn't anything been published, or anything changed because of it? Why do you keep asking the same 5 questions?
Saying Hello and Ghosting
This is a curious one that's come up on the official Python forum. A specific class at a specific university seems to be telling their students to sign up for the forums and say hello. The idea is probably that there are a lot of experienced Python people there for the students to ask questions and follow discussions. But what actually happens is that there is a category that is entirely made up of 100s of "Hello I'm ABC from XYZ University" topics from users that never interact with the forum again. It's just noise.
Another way I see this manifest is people joining the Flask/Pallets Discord server to say "Hello, I'm new to open source, how can I contribute." One of our moderators has a good friendly response they post each time, detailing what in the ecosystem needs attention, here's how to find issues, etc. But after this / other answers are given, the users never return.
Users also like to say "I'll work on this" on issues, but then never actually seem to work on it. I delete those comments when I come across them weeks later, so that other users don't think the issue is "taken". There's no need to ask to work on an issue. Just check that there's not an open PR already, ask questions if you need more details, and do it.
Code Reviews
Unfortunately, GitHub lets anyone leave code reviews on PRs, regardless of if they're a maintainer or existing contibutor. Sure, we can disable the "approve" and "reject" review types, but that still leaves the "comment" type that essentially looks and acts the same. If you're not familiar with a project, you're probably not in a position to review changes to it effectively. From the PR author's perspective, one review looks like another, so they have no idea this one isn't authoritative and might spend a bunch of time responding and reworking things before an actual maintainer notices.
A lot of these fall into the category of "we didn't ask for this", where instead of doing something the project explicitly asked for, the student did something their assignment asked for instead. When maintainers see these things hundreds of times, they lose patience. We know the student is doing it for an assignment, and is not actually going to stick around after the class is over. We don't want to invest our limited time in that.
This is not your fault as a student. It's your teacher's fault for not preparing you better. If you actually are interested in becoming a regular contributor to an open source project, that's great, and we have resources to help you get started. Find a project that interests you, not necessarily the big popular one but maybe one of its dependencies that gets less attention. Look for a contributing guide in the project, look at open issues that don't have an open PR, observe how other successful contributions were done. Take your time, stick around, and you'll learn plenty.