Suggestions that could be added to the read me for this repo

[theo-armour]

This repo is a general starting-off space for the Ladybug Tools collaboration. Items may include:

• Sandbox code and comments pre-repo stage - but that might otherwise clutter an existing repo
• Issues and comments that might apply to multiple repos
• Style guides and standards that might apply to multiple projects
• General coding or technical issues not related to specific projects such as
  • Calendars
  • FAQs
  • Utilities

Items for this repo should allow for aging and archiving so as to prevent a clutter of old, no longer used stuff

• Aging and archiving
  • Use year folders for last years things no longer
• Deprecation
  • Links to forks with newer versions

This repo does not replace:

• End user discussion on the Discourse Forum
• Project coding matters in their respective repos
• ladybug-tools.github.io for home page code and assets of wide utility and long duration such as logos and licenses

---

Any other fun ideas to add?

[AntoineDao]

I would consider this page more of a sitemap to where to get things and host mostly immutable content. My inspiration draws from the way the Kubernetes project has organised their community page. Sort of content they hold there is:

• Regular calendar events
• Status of different projects on their roadmaps
• Contribution guidelines
• Special Interest Group (SIG) folders
  • go-to contacts
  • SIG specific roadmap
  • Blogs
• Contributors folder with:
  • Getting started helpers
  • Future development proposals

I would personally rather not use year folders within git. If the status of some document changes then we can track those changes (if we really want to) with git. This means that when a user looks at the folders they expect exeverything to be in the right place according to topic and freshness of information rather than when it was written. Example: If our guidelines never change then there is no point putting them in the 2019 folder for other to dig into to find. We'd be better putting contrib guides in a dedicated folder called contrib and change it when change occurs.

Furthermore, I don't think this should contain any code (except for code that helps release this repo to a website or whatever) as my understanding is that it should be used to coordinate broader brush issues rather than serving as a sandbox place to show code. If code should me written then surely it is to be merged to the repo it belongs to? And if none exists then we can create a new repo or dump it in a gist if it's small enough.

[theo-armour]

@AntoineDao

I would consider this page more of a sitemap to where to get things and host mostly immutable content.

Good call.

I would personally rather not use year folders within git. If the status of some document changes then we can track those changes (if we really want to) with git.

The point I was trying to make was that it can be nice both to keep things tidy so there are not a lot of folders that peeps hardly look at and yet still quite available when peeps need a refresher on the rout not taken. But this is an issue that can be dealt with once we have the issue of lots of od folders. ;-)

Furthermore, I don't think this should contain any code...

Agreed, but this repo might be a place where docs are kept prior to creating a dedicated repo and while a plan for the new repo is being formulated and discussed. But what usually happens is that I make something and have no idea where to put it. For example, where would a good place be for 3D Pollinator JSON schema Viewers?

[AntoineDao]

For example, where would a good place be for 3D Pollinator JSON schema Viewers?

You could host it on a repo under your name? Then you can transfer it to ladybug-tools if it makes sense to merge it in.

[theo-armour]

You could host it on a repo under your name?

I could, but that is like putting my code in a box hidden under a rock in a deep hole that nobody knows about. ;)

What I am looking for are places where I can be useful and helpful - even with my limited and primitive ( but active and learning ) workflows.

[AntoineDao]

You can link to the project in this repo via issues or in readme's. So long as your repository is public then it's not under a rock or hidden 😄 Once they are ready to be shared then you can transfer the repository as a standalone one in ladybug. If the dev is relevant to another project than I'd reccomend working on your fork of that project and then making a PR when it's ready for folk to review and all.

Not that I don't want to see your code here but more that I fear that if we put too much then it loses focus and your work ends up being hidden under a pile of stuff that people don't want to look at because there's too much.