Development Process
This site was built quite a while ago so it doesn’t have the modern features of hot-reloading and the like. Instead development is done by tweaking things and re-running make. Some things can be done more easily. If you want to see a CSS change quickly you can modify one in the build directory (./ocaml.org/css) to see it in the browser (just be sure to copy the change back to the source CSS directory!).
This is a section from the ocaml.org/CONTRIBUTING.md file. I read the ending part that said,
Instead development is done by tweaking things and re-running make.
and it sounded like, whatever patch that’s supposed to be made to any bug, should be outside the ./ocaml.org/ directory, that is to its corresponding .md file outside the ./ocaml.org/ directory. Is this assumption true to all the files in the ./ocaml.org/?
1 Like
Hi @IkehAkinyemi welcome to the OCaml community 
!
Yes you are quite right. ocaml.org is the build directory that you will see after successfully running make. If you run make clean this directory gets deleted. Moreover, the entire directory is “gitignored”.
The point I was trying to make in that comment is that sometimes a lot of the bugs are minor CSS changes and it can be faster to tweak the CSS in the build directory rather than re-running make which can be slow (you could also tweak them with the browser dev tools too). Ultimately, however, the changes have to be propagated back to the source file (markdown, CSS, HTML etc.). Some files are simply copied to the build directory whilst others go through preprocessing and some scripts.
If you think the CONTRIBUTING.md doc can be made clearer please raise on issue on ocaml.org and I’d be happy to hear your suggestions :))
Thanks again for your interest.
Hello…
I want to be sure of the process of contributing to ocaml.org. So I’m asking:
- Who’s authorised to approve any issue reported/raised?
- Who assigns bug to contributors?
Also, I want to suggest that any issue reported should have a label, this makes it easier for contributors to identify and pick issues to contribute to.
I would love to help if any of these requires extra help to accomplish.
Regards.
Hi @IkehAkinyemi welcome to the OCaml community 
!
Thank you @patricoferris.
The point I was trying to make in that comment is that sometimes a lot of the bugs are minor CSS changes and it can be faster to tweak the CSS in the build directory rather than re-running make which can be slow (you could also tweak them with the browser dev tools too). Ultimately, however, the changes have to be propagated back to the source file (markdown, CSS, HTML etc.). Some files are simply copied to the build directory whilst others go through preprocessing and some scripts
Okay, that gives the suggestion that the skills required to contributing successfully to ocaml.org are knowledge of markdown, CSS in markdown and also converting HTML to markdown alongside the knowledge of HTML. This information would be very beneficial to our new contributors, open-sorcerers as I love to call it. The skills listing on the Outreachy page could need some updates if it’s okay I suggest that. I so much believe in ever-increasing good user experience for users, be it a newbie or experienced newcomer to any project, website or concept, and the above will help increase user experience.
If you think the CONTRIBUTING.md doc can be made clearer please raise on issue on ocaml .org and I’d be happy to hear your suggestions :))
I believe more guidance introduced into the CONTRIBUTING.md would help newcomers navigate and contribute to the project with much lesser confusion. It will be my greatest pleasure to help add these suggestions to CONTRIBUTING.md. I will draft out these suggestions and send them over to you by the weekend, hope that’s okay with you?
Thank you :))
1 Like
Let me try and clear things up (note I’m answering these questions from an Outreachy perspective):
- Who’s authorised to approve any issue reported/raised?
OCaml.org is open-source, anyone can raise any issue or bug report and it can be discussed by the maintainers and contributors to see if it makes sense. There’s always a chance it could be rejected later on but so far this is pretty rare. As part of Outreachy the issues mentioned in this thread are supposed to be good first ones. In terms of approving (merging) PRs that would most likely be @avsm (or other maintainers i.e. not me) – I’m trying to get applicants and PRs in a position where they’re ready to be merged before Anil sees them :))
- Who assigns bug to contributors?
From an Outreachy perspective so far that has been me. I try my best but there’s quite a few applicants (10+) and only one of me. Of course, like most open-source project’s it’s completely okay (and encouraged) for contributors to take on any issue they like unless it’s been explicitly given to someone else. There’s a fine balance to be struck here from an Outreachy perspective, because if we leave it as a free-for-all contributors who need a little more time to tackle a problem can sometimes be pressured by other eager contributors who want to work on the problem. At the same time, it can be a lot slower because I have to assign issues. I would also add I don’t think we anticipated the volume of eager and enthusiastic contributors too. This is something we would prepare for better in the future.
Also, I want to suggest that any issue reported should have a label
Totally agree. I would, but I don’t have the permissions. I’ll contact people that do :))
…knowledge of markdown, CSS in markdown and also converting HTML to markdown alongside the knowledge of HTML
So far on Outreachy we have two required skills HTML and a little OCaml. I agree, maybe we should add CSS and Markdown too. Perhaps we can pack out the contributing document some more with the build process. Again there’s a balance to be struck here, too many requirements might have driven people away. We’ve already lots of great contributions mainly in fixing HTML/CSS without any work on the OCaml glue that builds the site.
I believe more guidance introduced into the CONTRIBUTING.md would help newcomers navigate and contribute to the project with much lesser confusion…
Sounds fantastic! Please just open a PR on the repo with your ideas and we can work on them there.
Thank you so much for your willingness and help to improve the user experience.