-
Notifications
You must be signed in to change notification settings - Fork 328
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
Spec fix file #5565
Spec fix file #5565
Conversation
…js kept the contributing file same
Hi @milanholemans @Jwaegebaert i have let the contributing file remained as it was and added the spec file separatel. Kindly check and let me know |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few adjustments need to be made before we can continue @SanidhayaAgarwal. I've left several comments explaining the changes for each file. Let's try to keep to the scope defined in the issue for this PR.
docs/src/config/sidebars.js
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are too many changes here for what is needed. Please restore this file and let's just add a single navigation node under the section contributing
.
## New Command | ||
|
||
- [ ] The command doesn't introduce duplicate functionality that's already available in another command. | ||
- [ ] The command name follows the naming convention of service command (subcommand) verb. | ||
- [ ] The command name aligns as much as possible with existing commands and groups. | ||
- [ ] The command name aligns with the underlying API where appropriate. | ||
- [ ] The command name ends with a verb. | ||
- [ ] All nouns in the command name are singular. | ||
- [ ] Options follow the naming convention of not repeating the last noun, e.g., `spo web get --url` instead of `spo web get --webUrl`. | ||
- [ ] Options follow the `lowerCamelCase` naming convention. | ||
- [ ] Required options are denoted as `--required <required>`. | ||
- [ ] Optional options are denoted as `--optional [optional]`. | ||
- [ ] Shorts use a single dash followed by a single letter, e.g., `-i` instead of `-id`. | ||
- [ ] The command doesn't use global shorts like `-h` or `-o`. | ||
- [ ] All options have a clear description that indicates their purpose. | ||
- [ ] If the option belongs to a set, it clearly indicates all options in a set, e.g., "Specify `appId`, `objectId`, or `name`." | ||
- [ ] If the option expects predefined values (enum), it lists all allowed values. | ||
- [ ] If there are additional considerations for implementation/usage, they are included in the spec and later in the docs. | ||
- [ ] If the command requires additional scopes that aren't available in the CLI, these scopes are included in the spec. | ||
- [ ] If the command uses a preview API, it explicitly mentions it in the spec and later in the docs. | ||
- [ ] If the command returns multiple values, the spec explains what properties are returned for CSV and text output. | ||
|
||
## Enhancement | ||
|
||
- [ ] The enhancement doesn't introduce breaking changes. | ||
- [ ] If the enhancement is a breaking change, it's labeled as a breaking change, and the PR must open to the next major version branch, not main. The spec mentions this explicitly. | ||
- [ ] If the enhancement introduces new options, they're included in the spec following the same guidelines as for new commands. | ||
- [ ] If the enhancement introduces new functionality (new options or considerations), it explicitly mentions that docs should be updated in the PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more what we need for specification-checklist.mdx
but it's missing a few details e.g. the explanation of what a breaking change is under Enhancement
. Be sure to take over as much as possible from https://github.com/pnp/cli-microsoft365/wiki/Spec-checklist
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are too many items copied over here that originate from CONTRIBUTING.md
which don't belong in this file. Take a close look at the scope of the issue and let's stick to that for the time being.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure @Jwaegebaert give me 2 days time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, no rush!
Hey @SanidhayaAgarwal, just wanted to check in and see how everything's going with the changes. |
Closing due to lack of activity. |
🚀 Contribution to pnp/cli-microsoft365: Adding a Specification Checklist Document 🚀
Dear Maintainers and Contributors,
I am thrilled to submit this pull request, which introduces a valuable addition to our project's documentation. This enhancement enhances our collaborative development process by providing a detailed "Specification Checklist" document under the "Contributing" section.
📝 What's New?
✨ Specification Checklist: The heart of this contribution is the meticulously crafted "Specification Checklist" document. It defines comprehensive specifications for both new commands and enhancements in the pnp/cli-microsoft365 project. This checklist will serve as a valuable resource to ensure consistency, quality, and adherence to best practices in our development efforts.
🚀 Why It Matters
Ensures Consistency: The checklist ensures that all new commands and enhancements follow a consistent naming convention, options structure, and more, aligning with our project's standards.
Quality Assurance: By adhering to these specifications, we can maintain and improve the overall quality of our CLI commands.
Enhances Collaboration: Clear guidelines benefit all contributors, whether seasoned or newcomers, fostering a more collaborative environment.
Streamlined Documentation: This document will complement our existing documentation, making it easier for contributors to understand and follow our development process.
🙌 Your Feedback Matters!
We encourage everyone to review the new "Specification Checklist" document and provide feedback. Your insights and suggestions are crucial in refining our development process further.
📚 How to Access
You can find the "Specification Checklist" document under the "Contributing" section in the left navigation sidebar of our documentation.
💪 Contributing to Our Community
We believe that an active and engaged community is the backbone of any open-source project. We welcome all contributors, regardless of experience level, and we appreciate your dedication to making this project even better!
Thank you for your time and consideration. Let's continue to build an outstanding CLI tool together.
Cheers to open source and collaboration! 🌟
Best Regards,
Sanidhaya Agarwal