This thread is meant for interested open-content contributors to engage in discussions and explore ideas for creating effective documentation for the Docs repository.
Feel free to exchange valuable insights, share experiences, and gain guidance on how to get started with creating impactful documentation.
This would be a perfect space to discuss possible topics for Docs and where they would best fit in the project. For example, if you’re comfortable with a particular topic and wish to add an entry about it, but are unsure where it would fit in the project or how to get started, create a comment here and we can help you find out where that topic can live.
I was looking through the HTML chapter and I noticed that it was missing an entry on IDs. Since this attribute is often taught with the class attribute, I think it should be a new entry, and I would love to create it!
That’s great! HTML is quite fun. We do have an attribute entry on id, but definitely feel free to look over the entry and see if any information is missing or needs to be edited.
There is also a term entry on the class attribute so if you would like to take a look at both entries and make additions/edits, that would be awesome!
If there are any other attributes you can in mind that aren’t mentioned in HTML Attributes, please let us know.
Sounds like a good idea to me! The terms currently covered are all global attributes, meaning they can be applied to all types of tags.
src is a bit different because it’s specific to certain media tags (I recommend playing around with it on different browsers and referring to other documentation sites to see what it’s compatible with). Currently, the attribute terms cover only global attributes (compatible with all tags) and if you look at the actual entry itself, you’ll see that src is used as an example.
I’d recommend creating a pull request for the following additions and changes:
Create the src term entry under HTML attributes
Remove the src example from the attributes entry (incorporate this into the term entry you create)
Hope this makes sense but please let me know otherwise! Hope to see you in the Docs repo!
I was going through JavaScript statements in the documentation and realized that adding try...catch , throw , and switch statements would be beneficial. I would love to add these statements to JavaSCript docs.
I’ve noticed that the JavaScript objects docs do not currently cover getters, setters, and private class fields. Would it be possible for me to contribute by adding information about getters, setters, and private class fields to the documentation?
Great initiative! Thanks for looking around the JavaScript docs ^^ I took a look and while it looks like try/catch/throw and switch are already covered, a concept on accessor (getters…) and mutator(setters…) methods does seem to be missing.
After confirming with a fellow maintainer, I’ve gone ahead and created two issues:
A separate issue request will be added separately to cover classes, but for now, feel free to comment on one or both of the issues above which you helped brainstorm. After which I can assign you to them and you can open a pull request for each one.
Hi there, I have just started the Learn Javascript Syntax: Functions lesson and noticed that in the Functions article, one the of sentences could be grammatically improved;
Current:
A function is a reusable set of statements to perform a task or calculate a value. Functions can be passed one or more values and can return a value at the end of their execution.
Proposed change:
A function is a reusable set of statements to perform a task or calculate a value. Functions can pass one or more values and return a value at the end of their execution.
Also the document and text and image/alignment could be improved visually, happy to review anything else like this that can help improve the visual presentation of any of the material if needed?
I appreciate the correction, although the seemingly grammatical improvement actually changes the meaning of the sentence, also making it factually inaccurate. LMK if you have any concerns about this or would like clarification.
Otherwise, If you’re looking to provide visual supplements to some entries, I’d recommend looking at the HTML entries where there may be a chance for you to add in some images of what a particular block of HTML would appear like when rendered onto the browser.
Thanks for taking this initiative and also great idea about adding some more visuals to Docs ^^
@christine_yang I’m just working on an issue in the docs repo. The topic of the issue can be found under swift/protocols/encodable. While working on this issue, I found that it would be better to rename this document to codeable, because this protocol covers both encoding and decoding. But I’m new in the docs repo, so I want to ask if this is reasonable for you too.If so please let me know. If not I simply finish my work under the given name of the document.
@christine_yang I’m sorry to contact you again. Unfortunately I made a type mismatch in the conversation in the Term Entry. There I wrote that the title of the document should be changed to Encodeable. But like I mentioned here it should be Codeable. This is the new outcome from Apple for these kinds of protocols. I correct it in the Term Entry discussion too. Once more I want to excuse myself for this silly mistake.
@christine_yang I would like to see if possible to add any contribution in cyber security. There are a few changes I could make to existing content or possibly add content in? One sections that is not discussed is poperly tools or operating systems used in cybersecurity.
HTML is quite fun. We do have an 
