Issue 7174 - Add spec-kit constitution file#7255
Issue 7174 - Add spec-kit constitution file#7255mreynolds389 wants to merge 1 commit into389ds:mainfrom
Conversation
Description: Using a constitution file is the foundation of using spec-driven development. For now just add this file so the entire team and can use it if they deceide they want to use a spec-kit for development. relates: 389ds#7174 Reviewed by: ?
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Several of the referenced LDAP RFCs are historic/obsolete (e.g., 2251–2256, 2830, 2829) and newer 4510-series RFCs exist; consider either citing the current RFCs explicitly or clarifying that the list is illustrative/historic to avoid confusion for implementers.
- The Testing & Quality Assurance section overlaps quite a bit with the Testing Gates and Code Review Requirements subsections; you might want to consolidate or cross-reference these to reduce duplication and keep future updates to the rules in one place.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Several of the referenced LDAP RFCs are historic/obsolete (e.g., 2251–2256, 2830, 2829) and newer 4510-series RFCs exist; consider either citing the current RFCs explicitly or clarifying that the list is illustrative/historic to avoid confusion for implementers.
- The Testing & Quality Assurance section overlaps quite a bit with the Testing Gates and Code Review Requirements subsections; you might want to consolidate or cross-reference these to reduce duplication and keep future updates to the rules in one place.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| - LDIF format (RFC 2849) | ||
| - Operational attributes and controls (RFC 3673, RFC 4527) | ||
| - Network Information Service (RFC 2307) | ||
| - Other applicable RFCs as specified |
There was a problem hiding this comment.
Outdated RFCs (mostly), RFC 4510 obsolete a lot of them and specified which are the new ones, and RFC 4422 is the new for SASL.
|
|
||
| ## Governance | ||
|
|
||
| This constitution supersedes all other development practices and guidelines. All pull requests and code reviews MUST verify compliance with these principles. Amendments to this constitution require: |
There was a problem hiding this comment.
"Supersedes all other development practices" is pretty strong, IMO. I'd soften that to something like "complements existing project policies" with maintainer decision as the tiebreaker when things conflict. Otherwise this technically overrides release engineering, security processes, etc. which I don't think is the intent.
So to sum up -- that's good, we just should be careful with such strong assertions as it may create a worse result.
| The 389 Directory Server MUST be an open source, real-world, hardened directory service. All code MUST be extensively tested with sanitization tools before integration. The server MUST provide a rich feature set of fail-over and backup technologies to give administrators confidence their accounts are safe. Reliability is critical for enterprise deployments handling identity and organizational data. | ||
|
|
||
| ### II. Performance & Scalability (NON-NEGOTIABLE) | ||
| The server MUST be a high-performance LDAP server capable of handling thousands of operations per second and supporting hundreds of thousands of accounts. Database size MUST only be restricted by disk space. The server MUST support high throughput performance and multi-supplier replication for horizontal scaling to meet the needs of the most demanding environments - from small business to cloud deployments. |
There was a problem hiding this comment.
IMO, the absolute performance MUSTs are a bit tricky. "MUST support thousands of operations per second" and "MUST support hundreds of thousands of accounts" -- these are good but they're not testable at the PR level. And they are too broad.
Also, you suggest below -- "All pull requests and code reviews MUST verify compliance with these principles.". And these MUSTs are not testable.
Something like "for performance-affecting changes, validate no regression against established benchmarks" would be more practical and still provide a nice direction for the dev.
2 participants
Description:
Using a constitution file is the foundation of using spec-driven development. For now just add this file so the entire team and can use it if they deceide they want to use a spec-kit for development.
relates: #7174
Summary by Sourcery
Documentation: