You want to contribute to redoc? Great! Take a look at the roadmap below to see what general plans for the package are.
Please submit questions, bug reports, and requests in the issues tracker. Please submit bug reports with a minimal reprex and attach the associated word document.
If you plan to contribute code, go ahead and fork the repo and submit a pull request. A few notes:
- This package is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms. Why? We want contribution to be enjoyable and rewarding for everyone!
- If you have large change, please open an issue first to discuss.
- I’ll generally include contributors as authors in the DESCRIPTION file (with their permission) for most contributions that go beyond small typos in code or documentation.
- This package generally uses the rOpenSci packaging guidelines for style and structure.
- Documentation is generated by roxygen2. Please write documentation in code files and let it auto-generate documentation files. We use a recent version so documentation my be written in markdown
- We aim for testing that has high coverage and is robust. Include tests with any major contribution to code. Test your changes the package with goodpractice before submitting your change.
Roadmap
redoc is pretty experimental and I’m still figuring out its scope and architecture. Here are some topics I’m mulling over. Feel free to open an issue to discuss any of these:
- Understanding what the minimum features are required for the workflow to be viable, especially with the idea that word-using collaborators should never have to touch R or even know the origin of the document.
- Figuring out how to make the workflow more robust. There are a lot of ways collaborators could break the workflow. For instance, if the styles are changed in the word doc (something that happens rarely in my experience), the blocks are lost. Is there a better way to hold on to section metadata?
- Making redoc compatible with tools for generating richer Word Documents, such as worded/officedown, papaja, and
bookdown::word_document2(). Some redoc features will probably migrate to those other packages, or perhaps it will merge to create a package with a common framework building rich, reversible docx ouptuts.
- Making it possible to set many common document formatting properties in the YAML header. These could include margins, default fonts, default paragraph spacing, and line numbering. These may be features to put in worded/officedown. Maybe such changes could be detected in the doc and put into the YAML?
- Stuff in text boxes (again a worded/officer topic)
- Better formatting for highlighted outputs, and maybe finding a way to add a header/other message about them. (Adding headers not yet supported in officer).
- Finding a way to support citations, especially Endnote citations, which are the general bane of my existence. Some of this may be spun off into a more general Endnote package. (Hmm, possibly useful)
- Handling formats with figures/captions at the end of the file.
- Packaging up not just the Rmd but supporting files into the
docx file.
- Google Doc outputs. Google docs has a new API that exposes a JSON document model, which may enable this. It would require some considerable pandoc/lua work.
- Reversible Powerpoint? Whoah, nelly. Pandoc doesn’t even have a Powerpoint reader yet.
- Naming things and API/workflow. Package name, function names, etc., are all malleable, as are the appropriate sensible defaults.
- Sustainability. If this works out, should redoc live in an org or be absorbed into another package. Should there be an “officeverse”?