It depends on the project. Each project will have a list of issues that someone wants addressed. It might be a bug that needs fixing or a request for new functionality. You will want to choose work that interests you. I recommend starting small and working up to something interesting that would look good on a resume' :-)
You should submit multiple pull requests throughout the semester. The smaller and more focused a given request is improves the likelihood that it will be pulled into the project. Trying to submit 3 months of work in one big pull request is more likely to be met with resistance. It's also a potential waste if the direction you took conflicts with the direction desired by the project maintainers. I recommend you plan to submit several "bite sized" patches. If you want to tackle something big (ideally with a team), then i recommend you do that only after you have a few smaller patches under your belt, and you have checkpoint discussions with the project maintainers. For example, I would start with a statement of intent to make sure they agree with the design/approach and then sync-up in terms of progress/direction along the way.
The best general answer I can give is "partial credit". Your grade will be based on quality and quantity of your work as it relates to your objective. It will reflect feedback from me, Garry (our TA), and the project maintainer(s). Clearly a rejected pull request is bad and can be reasonably interpreted as a "zero" score from the project maintainer. Garry and I would take into account the details of the situation in arriving at a grade. As much as possible I want to be transparent with you on how you are progressing. In general, I want to make sure that everyone gets experience with successfully getting a patch incorporated into a project, which can sometimes mean working through disagreement from the project maintainer. I believe that these challenges should be overcome 90% of the time. It is partly because of this potential of rejection that I recommend multiple submissions. The more PRs you submit, the better your chances of acceptance.
If you are part of a N-person team, I would expect the team to produce at least N pull requests over the course of the semester, ensuring that each member of the team submits at least one PR. Each of the pull requests MAY contain work from multiple members of the team. I am open to the possibility that it doesn't make sense for a given project/team, but a case will need to be made to me on why an exception should be made.
Go for the more interesting project and see how far you can get by the end of the first day of the code sprint. If you change your mind then, it should be fine. After that though, you may be hurting your chances of success.
Apart from Scala's home, these should help: