OpenPrinting / OpenPrinting/libcupsfilters
Developer documentation for libcupsfilters2 API needed
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17
- Forks
- 71
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 13
Description
We have recently released the second generation of cups-filters which especially also contains the second generation of libcupsfilters (this repository).
This also includes that libcupsfilters2 provides a new API which needs to get documented, to allow everyone to easily use the resources of this library which are the hard work of many people during the last 20+ years. Especially also the old libcupsfilters1 API did not get documented at all which makes the new one even more important to get documented.
At OpenPrinting we want to reach a common documentation standard on all our repositories. Example for this is our CUPS repository, where we have API documentation based on appropriately formatted comments in the C code (assembled by CodeDoc) plus manually created introduction and examples.
This we also want to do with the developer documentation of our other libraries, including libcupsfilters.
Most of the API functions and data types of libcupsfilters2 already have he comments needed for auto-generation of API documentation, but some can be missing and also some improvement here and there could be needed. We also ned the manual part, introduction and examples to be written and everything assembled during the build process of the package.
See also our talk about our documentation plans from our micro-conference on Linux Plumbers 2022: slides. video
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the libcupsfilters2 C API comments and the existing CUPS CodeDoc documentation approach linked in the issue. Identify missing comments, the manual introduction and examples, and the build integration; done means the generated API documentation and manual sections are assembled during the package build.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100