oppia / oppia-web-developer-docs

Repo for Web developer documentation on Oppia. For contribution instructions, see: https://github.com/oppia/oppia/wiki/Wiki#contributing-to-the-wiki
Apache License 2.0
11 stars 94 forks source link

[Oppia-Wiki]Write Tutorials for Oppia-Wiki. #237

Open Ash-2k3 opened 9 months ago

Ash-2k3 commented 9 months ago

After setting Oppia up on their local machine, contributors are then asked to find an issue to work on. However, this can be tricky for contributors who are new to open source (or real-world software development), because they may not know how to navigate the codebase and find the relevant code to modify. We believe that, if we can help bridge this gap, then we can successfully introduce more contributors to open source and help them have a better experience with the project.

The aim of this project is therefore to write tutorials to bridge onboarding gaps, and verifying that these tutorials are effective in getting new contributors unstuck.

Checklist (see list of planned tutorials for more details):

If you'd like to claim this issue, please leave a comment here with a link to a Google Doc in which you have at least 50% of the tutorial written. (See examples in the list of planned tutorials doc and an already-implemented tutorial here.) If it looks good we will assign you to the relevant checkbox. Thanks!

vaishnavi192 commented 8 months ago

@Ash-2k3 Navigating PR review and submission page is already present right? here

rahat2134 commented 8 months ago

@Ash-2k3 assign the second issue (Navigating the Oppia PR review and submission process) to me , I can do it. My approach or a demo solution is -> # Tutorial: Oppia PR Review and Submission Process

Introduction

Welcome to the Oppia PR review and submission tutorial. This comprehensive guide will walk you through the intricacies of submitting a Pull Request on the Oppia GitHub repository. By following this tutorial, you'll gain hands-on experience with the PR submission process on a test repository, building your confidence as a developer.

Example Scenario

In this tutorial, we will submit a PR for a previous change, specifically the modification made in the About page's text from "Get Started with Oppia" to "Introducing Oppia."

Skills Covered

  1. Creating a PR with a detailed description.
  2. Navigating Continuous Integration (CI) checks, lint checks, and tests.
  3. Effectively responding to review comments.
  4. Applying the "revert and regression policy."

Procedure

Step 1: Before Writing Code - Choose a Descriptive Branch Name

Begin with a descriptive branch name and ensure it is based on the latest code in the develop branch.

Step 2: Make Commits Locally to Your Feature Branch

Each commit should be self-contained, accompanied by a descriptive commit message. Perform sanity checks, follow style rules, and conduct manual testing. Use git add . to stage changes and git commit -m "{{YOUR COMMIT MESSAGE HERE}}" to commit.

Step 3: Push Changes to Your GitHub Fork

Before pushing, perform manual testing, create a screen recording, and check changes using git diff upstream/develop. Push changes with git push origin {{YOUR BRANCH NAME}}.

Step 4: Create a Pull Request

Open a PR on your GitHub fork. Ensure the base repository is oppia/oppia with the base branch set to develop. Add a descriptive title, detailed description, and follow the PR checklist. Include the screen recording and click "Create pull request."

Step 5: Address Review Comments Until All Reviewers Approve

Respond to reviewer comments, merge develop into your branch to resolve conflicts, and make new commits to address comments. Test changes locally before pushing. Request reviewers to take another look after addressing comments.

Step 6: Make Sure All Continuous Integration Checks Pass

While waiting for approval, ensure all CI checks on GitHub Actions pass. If reviewers approve but CI checks are pending, assign yourself to the PR for merging later.

Step 7: Tidy Up

After the PR is merged, clean up by deleting the feature branch locally and on GitHub.

git branch -D {{YOUR BRANCH NAME}}
git push origin --delete {{YOUR BRANCH NAME}}

Step 8: Celebrate

Congratulations on contributing to Oppia! Explore more advanced PR workflows in Oppia's guide to common PR workflows.

By following these steps, you'll not only master the PR submission process but also become more comfortable with contributing to Oppia's codebase.

Feel free to ask for assistance on GitHub Discussions if any step is unclear. These seemingly small changes are an excellent starting point to familiarize yourself with Oppia's codebase.

seanlip commented 8 months ago

@rahat2134 Please see Ashwath's existing tutorial for the format we are looking for. Copying and summarizing the existing instructions is not sufficient -- it should be something specific that the contributor can work through.

Also this should be something that the contributor can work through safely and for pushing changes to github they might need to do that against a test repo. We don't want people spamming the oppia/oppia repo with PRs.

To be fair, the issue might be with the subject of the tutorial itself -- the others can be done locally but this one can't, so we might need to think more here about how to enable contributors to do this in a safe environment where their changes (and mistakes) won't affect anyone else. So I think the second tutorial in the list might need to be one of hte ones we tackle last, after we get more experience writing some of the others.

AfreenGHMomin commented 7 months ago

@Ash-2k3 assign an issue to me. You can check my work where I have written a tutorial for creating a snake game. The tutorial includes creating the environment and adding events to the game. link to the doc: https://docs.google.com/document/d/1Amp0diZxHnxOs1jvFPkHf9XAuYdcNz5Vel1ea15KBUg/edit?usp=sharing

seanlip commented 7 months ago

@AfreenGHMomin Just to be clear, the prerequisite for claiming this issue is a link to a Google Doc in which you have at least 50% written of the specific tutorial that you want to claim. This is because we also need to assess that you have mastery of the underlying technologies. Thanks!