You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is currently both boring and hideous, and there is no one to blame for this but me (Amy).
A long time ago I had discussed with the creative and talented @svteichman the idea of making a flowchart based around our lab philosophy: "what is your scientific question?" The point of all of these different packages is not to keep outdoing ourselves (though we do that occasionally as we learn more cool stuff about both science and statistics), but to solve different scientific problems using rigorous methodology. So, how do we help people figure out what software package they need for what they are trying to do.
While it would be ideal to have a glorious approach that updates the website each time we have a new package made public... we probably don't have the bandwidth to do that. That said, it would be great to make an intentional decision about what we do in 3 years to update both the webpage (probably easy-ish) and the flowchart (probably harder). Maybe we update the flowchart manually and the website programmatically.
eg We could move the software page to a github.io layout rather than our custom site layout (to make it programmatic). It could be a table
with
eg
name | scientific question | 2-3 sentences advertising the method
Opening the discussion for this here. I would call this important, but not urgent.
Case in point -- someone recently cited radEmu for something when I think they meant to cite tinyvamp... perhaps having a helpful directory of all the cool stuff that we've done might have helped
I like the idea of starting with something that is lower-hanging, like making the software page a github.io page! I started work on the software page months ago but got bogged down by the html code, so making it github.io (like our new blog) would be a nice way to get rid of this hurdle. I'm happy to work on this initial goal (table with name, scientific question, quick method explanation) in a github.io site when other statdivlab software issues calm down - I'll circle back to ideas in our next meeting!
I'm not sure how we could get it automatically updating unless we started adding information about name/method/explanation somewhere in each repo that it could pull from, but I could imagine doing something a little more basic like have a workflow that checks for new statdivlab public repos or packages every x months and sends out emails to subscribers if there are new packages that aren't listed in the table. Although that may be more trouble then it's worth, we could alternatively make a lab checklist for what to do when making a new repo/package public, and that could include updating the software github.io page.
Activity
adw96 commentedon Apr 18, 2025
Case in point -- someone recently cited radEmu for something when I think they meant to cite tinyvamp... perhaps having a helpful directory of all the cool stuff that we've done might have helped
svteichman commentedon Apr 18, 2025
I like the idea of starting with something that is lower-hanging, like making the software page a github.io page! I started work on the software page months ago but got bogged down by the html code, so making it github.io (like our new blog) would be a nice way to get rid of this hurdle. I'm happy to work on this initial goal (table with name, scientific question, quick method explanation) in a github.io site when other statdivlab software issues calm down - I'll circle back to ideas in our next meeting!
I'm not sure how we could get it automatically updating unless we started adding information about name/method/explanation somewhere in each repo that it could pull from, but I could imagine doing something a little more basic like have a workflow that checks for new statdivlab public repos or packages every x months and sends out emails to subscribers if there are new packages that aren't listed in the table. Although that may be more trouble then it's worth, we could alternatively make a lab checklist for what to do when making a new repo/package public, and that could include updating the software github.io page.