Skip to content

Added CONTRIBUTING.md file #58

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 61 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# Contributing to theupdateframework.io
Copy link
Contributor

@h4l0gen h4l0gen May 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Ayush9026 you did a wonderful work, I've just a small suggestion, should we add testing guidelines too, on how to test changes locally same as python-tuf CONTRIBUTING guideline.. Steps can be this:

  • Execute the following command to install the project's dependencies locally:
    $ yarn install

  • Start the Hugo development server to preview the website locally by running:
    $ hugo server

  • Once started, the website will be accessible at: http://localhost:1313/ by default. And review your changes.

Thank you 👍

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @h4l0gen,

Thank you for the kind words! 😊 That's a great suggestion. Adding testing guidelines for local changes will definitely help contributors. I'll include the steps you mentioned once @lukpueh and @joshuagl review it.

Thanks again for your valuable feedback! 🙌

We're excited that you're interested in contributing to the project! 🎉 Your contributions are highly valued and welcome. 🎉

## Issues & Pull Requests

### Creating an Issue

Before **creating** an Issue i.e for `bug`/`features`/`improvements` please follow these steps:


1.Check Existing Issues: Search to see if the issue already exists.

2.Provide Context: If it doesn't exist, create a new issue with as much detail as possible. Make sure to select the correct issue type (e.g. bug,documentation,feature).

3.Express Interest: If you want to work on the issue after it's been reviewed, mention this in your issue description.

### Working on an Issue

Before starting work on an existing issue, please follow these steps:

1. **Request Assignment**: Comment on the issue asking for it to be assigned to you.
2. **Prepare for Assignment**:
- Confirm that you have read the `CONTRIBUTING.md`.
- Ensure you have a functional development environment (you can build and run the project).
- Describe your intended approach to solving the issue.
- Include these points in one or more comments.
3. **Start Work**: Begin working on the issue only after it has been assigned to you.
4. **Avoid Conflicts**: Only start working on the issue and open a Pull Request after it has been assigned to you. This prevents confusion, duplicate work, and potential conflicts among contributors.
5. **Reference the Issue**: In your Pull Request, reference the issue (e.g., `This PR fixes #1234`). This ensures the issue is automatically closed when your Pull Request is merged.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Ayush9026, I think we don't have functionality of auto closing the issue. See even Referencing the issue in PR, we have to close it manually see . So IMO we should remove this part.

@lukpueh @joshuagl correct me if i am wrong 🙏

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @h4l0gen,

Thanks 🙏 for letting me know. If auto-closing isn't supported, I'll remove that part once @lukpueh and @joshuagl review it.



> **Notes:**
>
> - **Check the Assignees Box**: Before requesting to be assigned to an issue, check the `Assignees` box at the top of the page to see if it has already been assigned to someone else. If it has a current assignee but appears to be inactive, politely ask them if they are still working on it or if you might collaborate with them.
> - **Requesting Assignment**: Only request to be assigned to an issue if you know how to work on it.
> - **Seek Clarity**: If an issue is unclear, ask questions to get more information before requesting to be assigned. Avoid asking vague questions like "what do I do next?" or "how do I fix this?"
> - **Collaboration**: An issue can be assigned to multiple people if all parties agree to collaborate on it. The pull request can contain commits from different collaborators.
> - **Inactivity**: Any issue with no activity for 2 weeks will be unassigned and re-assigned to someone else.

Copy link
Contributor

@h4l0gen h4l0gen May 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should add DCO section clearly in CONTRIBUTING.md. In every CNCF project it is included see here in python-tuf, just for reference. WYT? @Ayush9026
Any suggestions @lukpueh @joshuagl

Thank you 👍

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great point. Including a DCO section would align with CNCF project standards and provide clarity for contributors. I’ll add this section to the CONTRIBUTING.md once @lukpueh and @joshuagl sir have reviewed it.

Thank you for the suggestion! 🙏


## Reviewing Pull Requests

We encourage everyone to review pull requests. It's a fantastic way to learn, network, and support each other.

### DOs

- Use inline comments to provide clear explanations for your suggestions.
- Offer inline suggestions to propose changes.
- Exercise patience and empathy when providing feedback on others' work.

### DON'Ts

- Avoid repeating feedback, as it creates unnecessary noise. Check the existing conversation and use GitHub reactions to agree or disagree with a comment.
- Do not approve pull requests without proper review just to improve your GitHub contributors graph.


## Style Guide

The theupdateframework.io site is built using HTML and Javascript.

Check out the set of contributing guides available at https://theupdateframework.readthedocs.io/en/latest/CONTRIBUTING.html
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, why referencing python-tuf's Instructions for contributors here? That page contains

  • DCO
  • Testing
  • Unit tests
  • Coverage
  • Auto formatting

Which completely based on python-tuf repo, does not relates to theupdateframework.io repository.

Thank you 👍

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @h4l0gen,

Thank you for the feedback! 👍 You’re right, referencing the python-tuf’s instructions isn't relevant here. I’ll update the contributing guide to better reflect the specifics of the theupdateframework.io repository.

Thanks for pointing that out! 🙌

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please just wait for official maintainer's review, before making any commit. I am not official maintainer, so there review is must required on if my review is correct or not. I hope you understand. Thank you 👍

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @h4l0gen ,

Of course, I understand. I'll wait for the official maintainers' review before making any changes.