Application began yesterday. Hope you are working on your proposal.
Yes will be publishing the draft soon .Is there a separate tag in jira to identify the technicle documentaion tasks.
Are you asking of the projects? if yes, there are the links.
I went through the project description as well.Since I already have worked with some of the endpoint when am contributing to reports module and core module and on the work am already doing.I have bit of knowledge on the swagger documentation of openMRS.
What I want to know is are we proceeding with making the swagger documentation more readable or we are proceeding with writing separate api documentation for all the endpoints
@burke is the mentor of that project I think he is the best person to answer you.
The ultimate goal is to have beautiful REST API documentation hosted alongside our Javadoc documentation at api.openmrs.org similar to what you see at developer.github.com/v3/. Having interactive examples interspersed within the text that run against the demo server would be even better.
Ideally, documentation would be coupled with code to avoid divergence/inconsistencies and editing it would be easy for developers as well as technical writers. Some thoughts on how this could be done:
- Manually write API documentation (e.g., in Markdown)
- Pros: straightforward for technical writers and could be easy for devs to edit as well
- Cons: lack of any coupling between docs & code increases chances for mismatch
- Introducing Markdown within Javadocs that could be programmatically turned into documentation.
- Pros: tight coupling of documentation with code
- Cons: might be harder for non-devs to contribute to documentation and harder to see the “big picture” to be consistent across the documentation, there would still likely be introductory or non-resource-specific documentation we’d want to include.
- Manually generate interactive examples from the code using Swagger and then intersperse documentation around the interactive examples.
- Pros: likely easier for non-devs to manage documentation
- Cons: looser coupling between code & documentation could reduce contributions from devs and lead to mismatch between docs & code
- Some combination of approaches (e.g., manually create intro & cross-cutting documentation for things like authentication and pull resource-specific documentation from Javadocs)
- Pros: tight coupling of documentation with code where it matters most while allowing for easier organization and handling of non-resource-specific content like intro, auth, etc.
- Cons: more moving pieces, might be harder for non-devs to contribute to resource-specific documentation
Given GSoD is about documentation, I think generating the text is most important – e.g., writing Markdown documentation introducing the API, covering authentication, and then for each resource with some (perhaps hidden) labelling that would make it easier to move the text into source code in the future if we went that direction.
The extent to which we can document using Swagger or a Swagger-friendly approach, the easier it would be to align this effort with exiting API documentation.
I was researching prettier API documentation for another project and found this list had most of the popular options:
Yes.I am going though the swagger documentation which was introduced by this project [Improved REST API Documentation Project - Midterm - Demo](http://GSoC Project For API documentation)
I think we can improve the swagger documentation as well with more proper responses errors and also describing more about the attributes in the api calls.
I already worked on similar project and done swagger documentations as well.
And also as in the github api documentation we can host the api documentation with all method based api documentation as well.
@atlcto I think most of the options that you shared are based on swagger documentation and open api spec is swager 3.0.I am already working on a apache project to have support for openapi spec 3 (PR :- https://github.com/apache/juneau/pull/44).And as I mentioned before we have swagger in place so I hope theres no need to migrate for a new swagger like documentation if am right @burke
If you’ve plans for supporting OpenAPI Spec 3, I also recommend that you update swagger core model classes to v3 as well.
Yes if that’s what we planning on doing on the documentation will start working on it as well.
I found a librarywhich can be helpful to full fill what you mentioned.Having markdown documentation align with already existing swagger .
The best thing about this is it now supports the openapi spec 3 as well.So if you’re already thinking about migrating to openapi spec 3 as gayan mentioned I can work on the base class migration and have support for openapi spec 3 as well.Since am already working with openmrs I hope it will be possible for me to do that as well.
And when it comes to this library we can use our swagger.yml files as an input and generate markdown documentation
So looking forward to hear from you.
I’m a tech writer interested in contributing to OpenMRS.
Your POC that links manually generated markup docs (getting started, etc) with Swagger output for the reference doc looks good to me!
If I can be of assistance, please let me know.
I’m looking forward to work on Developing User friendly Github Documentation Rest API documentation with GSOD and yeah maybe it will be migrated to OpenAPI Spec 3 as well yeah let’s see will let you know if we need any assistance. Btw thank you for asking.
Thanks for your reply. Please keep me updated, as I am very interested in contributing to the “Developing User friendly Github Documentation Rest API” GSOD project.
Hi @laurelmichaels Yes please if you found something useful please update me too am also intrested in contributing as tech writer in gsod for this project
hello ayesh, i can extend my services as technical writer in this project GSoD, Developing User friendly Github Documentation for REST API. please involve me in this project, if there is something i can contribute to. i am motivated to work on this project. i would appreciate reading from you. thanks ,
I replied to you on the main thread of the project.
@shafiq12 thanks you very much for showing great interest in this , we actually have more work that you can handle , can you join us every tuesday 4pm EAT (1pm UTC) at uberconference.com/openmrs to get started on many other tasks to do with documentation ?
or you are rather specifically interested in what ayesh is doing.
@burke do we still have tasks about REST API that other contributors can work on , even if they are not necessarily OpenMRS GSoD 2019 : official Tech Writers ?