initial commit

.buildinfo

@@ -0,0 +1,4 @@
+# Sphinx build info version 1
+# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
+config: b1043fe267ac9cc4ce3d3ae13f13e757
+tags: 645f666f9bcd5a90fca523b33c5a78b7

_sources/24ss/frontmatter.md

@@ -0,0 +1,28 @@
+# Frontmatter
+
+
+
+## Attendance
+
+Attendance will not be formally monitored; however, due to the interactive and collaborative essence of software engineering, this course is designed to encourage active participation and engagement in class sessions.
+
+```{warning}
+Please note, while attendance is not recorded, each quiz will contain questions directly related to our class discussions.  See [Quizzes](quizzes) below.
+```
+
+## Laboratory Sections
+
+All laboratory sections will be conducted asynchronously.
+
+## Quizzes
+(quizzes)=
+
+A minimum of 80% of the quiz content will be based on the assigned reading material. However, the remaining part of the quizzes will focus on class discussions. Regular attendance can have a positive impact on your grade, as it enhances your preparedness for the quizzes.
+
+## Course Project
+
+Start now, do not wait.
+
+## Midterm and Final Exams
+
+In this course, there will be no midterm or final exam. Instead, the comprehensive evaluation of your learning and understanding of Software Engineering will be through the course project divided into two parts. Part 1 of the project is due at the midpoint of the course, while Part 2 is due at the end of the examination period.

_sources/disclaimer.md

@@ -0,0 +1,3 @@
+# Disclaimer
+
+Please be aware that Artificial Intelligence (AI) tools have been employed in the creation of this documentation (including this disclaimer). These tools were used as an adjunct to augment and enrich both the creative and analytical aspects of our work.  While AI served as a supportive aid, its contributions have been examined and refined to ensure they align with our overarching objectives. This statement serves to maintain transparency and acknowledge the role of AI as an instrumental, yet supplementary component in our process.

_sources/graded_artifacts/course_project/course_project.md

@@ -0,0 +1,51 @@
+# Course Project
+
+For the course project, you are tasked with making a significant contribution to an open-source project on GitHub. Your primary objective involves developing and submitting a substantial modification, be it an enhancement, a bug fix, or new features. Ensure that these contributions are meticulously crafted to enhance their chances of being accepted by the project's maintainers.
+
+Your responsibilities include choosing an open-source project, pinpointing a specific change to implement, understanding the contribution guidelines, actively participating in the project, documenting your insights, and reflecting on the experience.
+
+While you have considerable freedom in choosing the project and type of contribution (subject to certain requirements and recommendations), your selection should be based on your ability to fulfill all the project's requirements. Avoid choosing a project or task that may hinder your ability to meet any of these requirements.
+
+In projects like this, it's common for students to feel worried or stressed as the due date approaches; this often stems from realizing that their project or contribution, although not against the rules, could make it challenging to provide all the necessary evidence to earn full points for the course project.  To prevent this, it's advisable to initially work in a way that covers all requirements broadly. Once you're confident that all requirements are met, you can then focus on more in-depth aspects of the project.
+
+:::{tip}
+Successfully completing this project can serve as an excellent discussion topic in technical interviews, particularly with top-tier companies. Therefore, consider choosing a slightly more ambitious task to enhance your ability to "show off" later. Don't focus solely on the task's complexity; some employers may place more importance on factors such as the size of the codebase, the number of active developers, the rigor of the development process, the extent of testing and quality assurance, the use of analysis tools, adherence to the required project design or architecture, among others.
+:::
+
+## Requirements
+
+The following aspects of project or task selection are firm requirements and cannot be waived. If you found a project or task that seems really great but does not satisfy one of these rules, you must regretfully pick another instead. 
+
+It is easy for students to mess up by working depth first, you should work breadth first to ensure that you cover all of the requirements.
+
+Here are the revised project requirements with improved grammar:
+
+1. The project should be scoped to ensure a minimum commitment of approximately 24 hours **per team member**. For instance, you might spend around 7 hours selecting a project and understanding its context; approximately 12 hours for preparing a work list, designing, and implementing your changes; and about 5 hours for reflection and report preparation.
+2. You have the option to undertake either one large task or multiple smaller tasks. If working in a team, ensure the workload is doubled. Select tasks that benefit from teamwork and are suitable for your team size — avoid choosing small, independent tasks for each team member.
+   > It's acceptable to list several tasks and stop after completing a few, provided you've spent the required time and have all necessary reporting materials.
+   > Likewise, you can choose a large task and break it down into smaller parts, stopping once you've devoted the required time and compiled all required reporting materials.
+3. Your task(s) must be sourced from a bug report or feature request in the project's public database. Adhere to the project's established protocols for communication and tracking open issues. Both the chosen project and the specific issue(s) must be publicly available on GitHub.
+4. You are free to select a project, project type, or task type with which you are already familiar. Some students may use their existing expertise to simplify the process, while others might explore new areas for learning. Both approaches are valid.
+5. You must focus on just one project. This applies even to teams of two; you must concentrate on a single project, not multiple projects simultaneously. All tasks should be from the same project.
+6. Avoid selecting a project that you or another UC student own or manage. However, projects managed by non-student organizations at UC are permissible.
+7. You must not have any involvement in the creation of the bug report or feature request. Refrain from fabricating a project need or generating your own.
+8. Do not intentionally choose an issue created by another UC student, nor have your code reviewed by one. If you are acquainted with a project maintainer or face any other conflict of interest, select issues that were posted before the semester began.
+9. The task must involve modifications to the project's source code. Tasks solely related to graphics, documentation, or design are not suitable.
+
+
+## Recommendations
+
+Here are some strongly advised recommendations that you should consider following closely. Although you have the option to overlook these suggestions, doing so could likely result in a lower grade due to insufficient evidence for meeting all reporting requirements.
+
+1. Opt for an active project with numerous contributors. You can gauge activity levels using GitHub's statistics for comparison across different projects.
+2. Avoid tasks limited to implementing an algorithm or data structure. Such tasks may not provide ample evidence of your proficiency in requirements elicitation, code comprehension, and dependent coding within an extensive codebase not authored by you, as the requirements for algorithms are often too straightforward.
+3. Choose tasks that involve more than just frontend activities with no testing component. Pure frontend tasks might not offer sufficient proof of your mastery in quality assurance aspects like testing and code reviews.
+4. Steer clear of tasks or projects involving sensitive information that cannot be included in your report. For instance, tasks requiring secret keys, database access, or other confidential information that prevent you from sharing screenshots to demonstrate your work should be avoided.
+5. Be aware of the possibility that another contributor might complete a chosen task before you. While some projects allow you to reserve issues, not all do. Consider this risk when selecting tasks.
+6. Remember, your contribution doesn't need to be accepted for you to receive full credit. Grading will be based on a specific rubric, focusing on various aspects of your work and not solely on acceptance by the project.
+7. Consider taking actions beyond the project's strict requirements to enhance your report. For instance, communicating with a project maintainer about non-functional requirements for your patch can provide opportunities to demonstrate your understanding of quality properties and requirements elicitation.
+8. Review at least two of the example reports provided at the bottom of this page. They can help clarify the extent of evidence needed for full credit, as course staff may not be able to answer such specific questions beyond the provided rubrics.
+9. Reflect on the typical scope of pull requests and the course's emphasis on code reading versus writing. For instance, in maintenance tasks, understanding where and how to make changes often proves more challenging than the change itself, which might be minor.
+
+
+[](https://opensource.guide/how-to-contribute/)