-
Notifications
You must be signed in to change notification settings - Fork 49
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
Add editorial board #353
base: main
Are you sure you want to change the base?
Add editorial board #353
Conversation
@@ -40,18 +40,24 @@ Here are the different categories of expected stakeholders for the Coq Platform: | |||
|
|||
- Packages are typically included on user request via a github issue. | |||
|
|||
- Requests should contain a justification. Good justifications are usage of the package in a regular course or a course with more than 25 attendees or usage of the package as prerequisite in at least three other packages or research developments by authors other than the author of the original package. | |||
- Requests should contain a justification. Example justifications are usage of the package in a regular course or a course with a large audience or usage of the package as prerequisite in at least three other packages or research developments by authors other than the author of the original package. |
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.
I've always felt that if enforced harshly, this paragraph (both before and after the current change) has the potential to lead to "chicken and egg" problems, where researchers feel packages need to be in the Platform before they use them, but packages need to have serious research users to become included.
How about mentioning explicitly something about the possibility of exceptions for packages that fill a specific important niche? One example would be the (already included) LibHyps package.
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.
Indeed "filling an important niche" is also a valid justification and one could add this as example.
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.
I will do it, but in another branch, to avoid triggering CI at each minute change in this documentation page.
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 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.
@ybertot : I plan to implement the suggestion by Andew in Zulip. In the mean time I will cancel the runs manually (I anyway tend to do this, but I was on vacation yesterday).
Adds simple references to an editorial board, mentioned mainly in the process for inclusion of new packages.
On the other hand, the members of the editorial board are not mentioned personally. I believe this information should appear in a different file.