Grassroots organizing isn’t enough to achieve meaningful change.
Sooner or later you need people in the room,
on the committee,
to get what you want on the agenda and then vote for it.
you will always be working around or against the rules
instead of having the rules work for you.
Everyone from the NRA to the ACLU sends questions to people running for public office
and publish scoresheets ranking the candidates based on their responses and their legislative track record.
What if an open science organization (or a group of them) did that
for people who are running for the executive or boards of various research societies?
Questions could include:
What specific steps will you take to ensure that people developing research software are given institutional recognition for their work?
What changes to the society’s model curriculum will you push for relating to open data, open science, and reproducible research?
What will you do to increase diversity and inclusivity within the society?
Just asking the questions puts the issues on the agenda,
and publishing the responses (with or without a scoring or ranking) will get even more attention.
I think it would be a low-cost, low-risk way to reward people who care about open science,
and recognition for all the work people do (not just the papers they publish).
I think it would encourage younger people to run for office.
I’ve been telling myself for almost twenty-five years that we just need to be patient—that
sooner or later the generation that’s grown up believing in open will find themselves in positions of power
and make the changes we need.
I’m tired of waiting,
and if the politics of the last five years have taught us anything,
it’s that progress isn’t inevitable.
If we want a better world, we need to build it.
Asking the people who want to lead us whether they’re going to do that or not
seems like a good first step.
Today is my first day as Head of Education at Metabase.
I’m excited to be starting a new adventure,
and for the chance to help millions of people find answers in their data.
I have a lot to learn—I hope you’ll enjoy following along as I do.
The previous post in this series
and Building Tech Together.
Here’s more detail on the helper scripts I had to write
to work around Jekyll’s inadequacies,
in the order in which they run during a full build.
All in all they are 2600 lines of Python;
rebuilding some of them would be a rich source of exercises
for a second-year course on software design and testing.
convert the YAML-format bibliography in _data/bibliography.yml
to a Markdown file bibliography/index.md.
I used YAML rather than BibTeX because it’s easier to read and process;
I’m surprised this isn’t already common practice.
extract index keys from Markdown source to create _data/index.yml,
which is then processed by Jekyll to create an index page.
generate serial numbers for chapters and appendices, figures, and tables,
and put them in _data/numbering.yml.
find all glossary definitions and store them in _data/terms.yml
so that each chapter can start with a list of the terms it defines.
check that all citations resolve and all bibliography entries are used.
check that all glossary entries resolve (including cross-references within the glossary)
and that all existing entries are referenced.
The glossary is stored in Glosario format,
and the entries are mix of some cherry-picked from Glosario itself
and some I’ve written for these books.
look for text inclusions (e.g., sample programs) that are too long to fit on a single printed page.
STJS has several of these;
if I stick with this template,
I’ll modify this script and some of the others
so that directives in the Markdown source will turn off warnings for specific inclusions.
check that all code blocks have a recognized language type.
(I can’t train my hands to be consistent about txt versus text or py versus python.)
check that the generated HTML only uses expected tags and attributes.
compare the link definitions in _config.yml
with the [name][link] references in the Markdown source files
to make sure that all definitions are used and all references to links resolve.
I’d really like to put link definitions in an external YAML file in the _data directory,
but Jekyll doesn’t support that;
as explained here,
they have to go in a single YAML-formatted string in _config.yml.
make sure that all cross-references to chapters/appendices, figures, and tables resolve.
prep-spelling.py and check-spelling.py:
the first strips code blocks from the generated HTML,
which is then piped to aspell to create a list of unknown words;
the second compares that list with the one stored in _data/spelling.txt
and produces a list of unknown words.
convert the generated HTML to LaTeX, which is then used to produce a PDF.
I’ve used Pandoc for several previous projects;
500 lines of Python that does exactly what I want and produces comprehensible error messages
is a lot easier for me to maintain.
I also have:
show the number of words in each chapter along with the total word count.
print a list of all tags and attributes in the generated HTML.
display all the embedded to-do items along with a count of how many there are.
display all index terms and the locations of all references to them.
(This helps me catch things like singular-vs.-plural inconsistencies in index terms.)
display the number of pages in each chapter of the final PDF.
which teaches software design by building small versions of the tools programmers use themselves.
Comments and feedback would be very welcome.
Turned a pile of notes into a rough draft of Building Software Together,
which is a guide for undergraduates embarking on their first team software project.
The sections on security and fairness are still unsatisfying,
but I hope it’s useful,
and feedback would be even more welcome.
Built yet another Jekyll template for writing books like these.
It relies on a bunch of Python scripts to make up for Jekyll’s inadequacies,
and I use another Python script to convert the generated HTML to LaTeX so that I can produce a PDF
(because that’s easier to maintain than customized Pandoc),
but it’s working well enough that I might get around to documenting it for others to use as well.
Discovered the hard way that if you don’t use WordPress for 20 years,
you forget everything you once knew about PHP.
Gave a couple of talks and signed up to give a couple more.
Read about two dozen papers.
(Thank you, Alexandra,
for making this possible.)
Added about 20,000 words to the novel I’m working on.
I’m 4800 words short of my target for the nine weeks,
so I did well or poorly depending on how you look.
Exercised and played guitar four or five times a week.
My blood pressure and BMI are still higher than they should be for someone with my family history of heart disease,
and progress on guitar is still frustratingly slow,
but I’m mostly satisfied.
Built some lids for our garden boxes
and generally got the back yard ready for another spring.
It’s unlikely we’ll do any house renos this summer
(Ontario is going into another lockdown thanks to the Ford government’s cowardice and incompetence),
but I’m hoping we can take advantage of working from home the way we did last year.
Played several hundred games of Hive
and lost most of them.
I do all right if I survive the opening,
but that’s a big “if” right now.
If you’d like to trounce me, I’m gvwilson on Board Game Arena.