aswihart

Dependencies should be updated according to your development cycle, not the cycle of each of your dependencies. For example you might want to update dependencies all at once when you begin a release development cycle, as opposed to when each dependency completes theirs.

We're in this space and our approach was to supplement Dependabot rather than replace it. Our app (https://www.infield.ai) focuses more on the project management and team coordination aspect of dependency management. We break upgrade work down into three swim lanes: a) individual upgrades that are required in order to address a known security vulnerability (reactive, most addressed by Dependabot) b) medium-priority upgrades due to staleness or abandonedness, and c) framework upgrades that may take several months to complete, like upgrading Rails or Django. Our software helps you prioritize the work in each of these buckets, record what work has been done, and track your libyear over time so you can manage your maintenance rotation.

Figuring out whether the upgrade is safe is a hard problem. I've found renovate most successful in frontend JS projects where you have a ton of dependencies all with new versions coming out all the time, most of which are non-breaking, and where the danger of a bad upgrade is not that large.

For backend work or once you've gotten the easy stuff out of the way you really need to review the changelog, assess the risk, and do the upgrade safely (disclosure: my startup Infield is in this space).

hey all! for anyone interested in open source, my team just launched a substack called Once a Maintainer. Each week we interview a maintainer and ask them about the work that they do. We're trying to bring a more human, storytelling element to the sometimes thankless work of maintaining OSS. For our first post we talk to Joakim Antman, who maintains the ruby gem jwt. Feedback welcome.

lol yeah we need more Juiceros

- don't talk over women in meetings - don't ask women to do informal "secretarial work" for the group, e.g. note-taking, summarizing meetings, ordering the Christmas cards, buying birthday presents, ordering furniture - don't expect all women to have the same personality (warm, bubbly, cold, bitchy, etc.) - don't say dumb shit about maternity leave (the day I came back from maternity leave, my boss told me he wished he had been on "vacation" for 3 months) - hire men too for traditionally "women-dominated" roles, e.g. office manager, customer support, chief of staff, HR. Show that gender balance cuts both ways. - don't make assumptions for women with kids (oh, you probably can't come to that happy hour, etc.) that you wouldn't make for men with kids

I personally think on-campus recruiting is a great way to get young women into tech. I loved mentoring the young women we hired, managing them, promoting them, etc. (before I left to found my own company).

Congrats on the launch! Beautiful site. I'd like more info about how you ship the art before buying. I found your FAQ after a little digging, but it didn't really give me comfort that you ship using a method that is particularly suited to fine art. Also, I noticed a few listings say that they come framed. For these I'd want to see the frame, they vary so much in style and size.

I missed this comment earlier - we can pilot with sample/fake data to give the user a sense of how the system works and what workflows within it work best for their company. The versioning/diffs wouldn't make much sense, but that's probably ok.

Interesting, I just came across Frictionless recently as part of the FISD group that's trying to implement a set of standards across the financial industry for documenting datasets.

We actually built in the concept of "display names" for exactly this purpose. You want to keep the actual field name in the schema so that ingestion works properly, but you also want to describe the field as helpfully as possible. In another comment, Steve mentioned that we are trying to tackle the first problem you mention (how much overlap is there between my dataset and other external factors) with the concept of creating dataset intersection or relevance scores.

We would love to do that at some point. There is tons of open data out there, but not a lot of it has useful descriptions at the field level (only the dataset level), so it would take some time to put a collection together that is robust. Also the demo on our splash page is a demo of the artifact we create (i.e. the published dictionary) only. The other side of the web app is a management layer to bundle datasets into collections, annotate fields, configure sample sets, and share the artifacts. We'll work on fleshing out our demo to show what the system looks like when there are hundreds or thousands of datasets.

This made our day : ) Thank you!

We think data-as-a-service is a new and growing category, and this includes startups we would consider "pure" data companies (e.g. a company that sells data on airfares across the web) and companies that have been around for decades selling csvs that they deliver over FTP (e.g. a giant company like ADP that sells payroll processing data). Based on our backgrounds we have a fair amount of experience in the alternative data space, which is basically any data that might have some signal to a hedge fund that isn't market data. I'm finding that the providers in that space are interested in expanding their customer base to corporates (e.g. Walmart, McDonalds) whereas the providers currently selling to corporates are interested in expanding into alternative data.

(This is Allison) - thank you! It's interesting for us to see how the problem is handled at different types of organizations, because as you point out the data team knows the underlying data best but is not often customer-facing.