https://final-project-samarth-yunyi-xcgs.onrender.com/
The team project has four parts -- proposal, implementation, checkpoint, and presentation. Each of the sections is described below. Pay attention to the due dates and deliverables for each section.
Saturday, March 22, 2024 at 11:59 PM
-
Define at least three distinct functional requirements you want to implement to extend the fake stack overflow app. Recall functional requirements correspond to things a user can do on the application. In the past, students have added the following features. You can use these features for ideas but are not limited to them. Feel free to use your imagination to develop the proposed feature set.
- Allow users to create accounts, manage their accounts, and their activity.
- Content moderation mechanisms.
- Automatically infer post tags/themes from the post content.
- Commenting posts.
- Voting on posts.
- Improve the user interface using Material UI.
- Allow users to rate posts and accept answers to a question.
- Help users earn badges and reputation points.
- Allowing users with similar interests and values to create communities.
- A bot that creates automatic answers to questions posed, subject to admin verification.
-
Define at least one non-functional requirement. Recall a non functional requirement is not something that the user can do but affects usability of the application. In the past students have added the following non functional requirements:
- Improve the user interface using Material UI.
- Improve accessibility so it is accessible to all kinds of users.
- Improve the performance of the application using server-side caching or pagination.
- Refactor the design of the React client by introducing React routing or context and reducers.
- Define an alternative arcitecture using architectural patterns such as microservices.
-
For each functional requirement, define the requirements as user stories. At the very least each feature should have a user story. There is no limit on the number of user stories.
Each user story must be defined as an issue in GitHub and have the following format:
Feature: feature name Context: The socio-historical context for the proposed feature Description: As a `user` I want to `action` so that I can `goal` Scenarios: Acceptance criteria defined as `Given When Then` scenarios.The
goalof the feature description must accurately reflect the values you want to embed into the design of your application.The acceptance criteria must describe both valid cases and error cases for full credit.
The user stories should represent the minimal viable product (MVP). An MVP is a basic version of a product that can be released for feedback. You can go beyond the defined user stories in the final project. However, you will be graded based on the user stories you define in the proposal. Minor changes to user stories will be allowed in the final submission.
A non-functional requirement must be defined as a GitHub issue in the following format:
Description: one line description of the requirment. Goal: What is the purpose? Enablers: A list of exploratory and technical enablers required to implement the requirement. Acceptance Scenario: A list of measurable items that will indicate that the requirement is complete.
Review the module on user stories for reference.
- A list of issues in this repository's issues tab.
- A GitHub Project with all issues listed as ToDos.
- The link to this repository in the Canvas assignment for project proposal.
- You will get full credit if your proposed features are approved.
- You will get no credit if your proposal is rejected.
- Reasons for proposal rejection:
- Failure to define three distinct functional requirements and one non functional requirement.
- Failure to record requirements as GitHub issues.
- Failure to create a GitHub Project.
- Failure to comply with the given format.
- The stories are not expressed in a measurable manner and are vaguely specified.
You are encouraged to use the following resources to inform the design and specification of the proposed features.
Bias
-
Gender differences in participation and reward on Stack Overflow
-
The Impact of Surface Features on Choice of (in) Secure Answers by Stackoverflow Readers
Trust
- Understanding stack overflow code quality: A recommendation of caution
- Stack overflow considered harmful? the impact of copy-paste on android application security
- An Empirical Study of Obsolete Answers on Stack Overflow
Socio-historical Contexts
- Understanding and evaluating the behavior of technical users. A study of developer interaction at StackOverflow
- Is Stack Overflow Obsolete? An Empirical Study of the Characteristics of ChatGPT Answers to Stack Overflow Questions
- Impact of individualism and collectivism cultural profiles on the behaviour of software developers: A study of stack overflow
- Thank you for being nice: Investigating Perspectives Towards Social Feedback on Stack Overflow
Content Moderation
Hate Speech
Read the project implementation details here.
Final Project Due Date: Friday, April 18, 2024 at 11:59 PM
You are expected to submit a pull request (PR) for review. The course staff will review the pull request and provide actionable feedback. We expect that you will have addressed concerns and comments raised in the reviewed PR in the final project submission. In the pull request comments you must describe which requirements you have worked on thus far. The best way to describe this is reference the user story in the comment and list the acceptance criteria that have been met and the ones that are remaining.
Checkpoint Due Date: Saturday, April 5, 2024
Submit your team's GitHub URL in Canvas.
See grading section in the project implementation description document (link above). Additonally you must submit the following:
- This repository's link in the Canvas assignment for final project.
- A README-instructions.md file with the following:
- Instructions to test the deployed application on Render
- Instructions to run the jest and cypress test cases.
- Instructions to generate the coverage report for jest tests.
- Instructions to generate the CodeQL report for your application's server.
- Instructions to set environment variables that one may need to run any scripts or tests.
- Submit the peer-evaluation survey.
- Any additional information (if any) about your implemention that you would like to inform the grader should be documented in README-misc.md.
Read the the expectations of the final presentation here. In the same document you will find a link to schedule your final presentation. You must select a time slot between Apr 22 - Apr 25. The presentation will be online. Carefully read the instructions before scheduling the presentation.
- Presentation slides in the Canvas assignment for the final project presentation.