Other chapters

[sckott]

Right now we have:

• Help (i.e., how can FH community get help from DaSLers wrt code)
• Contributing
• Style
• Code review
• Documentation
• Package versioning

What other chapters might we want to include? @seankross @vortexing Some thoughts:

• Security
  • Package Secrets (managing API keys, passwords, etc, both for exported methods and internal testing)
  • Examples (how do we have really good examples when our target users are using data that can't be easily used within examples in pkg docs)
  • Data (how to not leak/expose secure data)
• Package maintenance
  • Package versioning (existing chapter above)
  • Releasing to CRAN or PyPI
  • (for everything else refer people to R Pkgs book?)
• Package versioning (I want us to be consistent wrt versioning, but what do you think?) (now in book)

Potential resource for python pkgs https://py-pkgs.org/welcome kinda similar to R Pkgs book

[seankross]

Package versioning (I want use to be consistent wrt versioning, but what do you think?)

we definitely need this

Security (wrt data and code) Package maintenance (do we want to be opinionated about this?)

I would want to know what chapter section headings you would have in mind before having a strong opinion

[sckott]

Cool. I'll work on pkg versioning, and put in some notes about headings for the other potential chapters

[sckott]

@seankross i could use your feedback on the security chapter. what do we want to recommend people do with respect to data and examples in package docs? should we mention something about additional documentation on sciwiki? and/or some other place where we can have examples that run though using real data sources?

[sckott]

@seankross i'm thinking that it doesn't make sense to have both Help and Contributing chapters. That is, I think this guide's scope is constrained to the software that DaSL maintains. If that's the case, we don't need to point to data house calls for example as that's helping folks with their software/data/etc. I think we just want to remove the Help chapter, and retain the Contributing chapter. Yeah?

[seankross]

I think this guide's scope is constrained to the software that DaSL maintains.

I agree.

we don't need to point to data house calls for example as that's helping folks with their software/data/etc.

I agree.

I think we just want to remove the Help chapter, and retain the Contributing chapter. Yeah?

Sounds good to me.

[seankross]

@sckott in terms of security chapter feedback, I think I want to do a PR on that chapter first.

[sckott]

Okay, thanks for the feedback on help/contributing.

Okay, i'll do a PR for security

[sckott]

Conventions might be a chapter we need. e.g., if we have default repo labels that could go in there