Update readme to denote the business logic used to validate commits
I've included Wayne as one of the resident guru's over the business logic and terminology when discussing the ECA validation logic. The idea behind this PR is to track when there are updates to the validation logic, and the issue/pull request associated with the change for additional context.
Signed-off-by: Martin Lowe martin.lowe@eclipse-foundation.org
Merge request reports
Activity
https://github.com/autumnfound/git-eca-rest-api/tree/malowe/master/bl-readme#validation-logic easier to read version available here.
Review: Changes requested
Thanks for getting started on this today!
I really think this will help folks understand how our validation works. Wayne is definitely the topic expert but I do have some feedback:
- Signed commit is a bit confusing. To me, a signed commit is https://docs.github.com/en/github/authenticating-to-github/signing-commits. I recommend that we replace "In order to be considered a signed commit" with "In order to be considered a valid commit"
- I think we should change the heading from "Validation Logic" to "Validation Rules" or "What is a valid commit under the ECA?"
- Include a link to ECA form when referring to ECA: https://accounts.eclipse.org/user/eca
- We should add a link to the Bots project for section 2.1 (unless we have documentation about that endpoint): https://github.com/EclipseFdn/projects-bots-api
- Please make sure that each issue number is a link to the correct issue.
- We need to describe the difference between a non-project repo and a project repository by explaining how we determine their state.
We can do that with some text + link to our Project API Documentation: https://api.eclipse.org/#tag/Projects
