gh config set telemetry disabled

1. Mostly use the mobile app, and take photos and upload observations directly from there. Local photo collection either isn't a priority or is backed up by their phone's cloud sync.

2. Mostly use inaturalist.org via a desktop browser, with either a standalone digital camera or mobile photos synced to desktop. Local filesystem (hopefully plus backups) is the source of truth.

I have been working on a desktop application[2] with a long-term goal of full bidirectional sync, and a secondary goal of offline usage. The current feature set is fairly modest and read-only, though, focusing on organizing local photos using data from iNat.

[1] https://www.inaturalist.org/pages/about

[2] https://github.com/pyinat/naturtag

https://github.com/inaturalist/inaturalist/blob/main/app/ass...

https://github.com/inaturalist/inaturalist/blob/main/app/ass...

https://github.com/inaturalist/inaturalist/blob/main/app/ass...

https://www.gbif.org/dataset/50c9509d-22c7-4a22-a47d-8c48425...

https://www.gbif.org/dataset/8a863029-f435-446a-821e-275f4f6...

The iNat API certainly has some quirks and shortcomings, but in terms of usability it's uncommonly good compared to most biodiversity platforms. I maintain the python API client[1], which is used for data visualizations, doing useful things with your own observation data (which is how I got into it), Jupyter notebooks, Discord bots, and some research/education workflows.

[1] https://github.com/pyinat/pyinaturalist

Discussion: https://news.ycombinator.com/item?id=46934404

My use case looks roughly like this: for a given project (as in hobby/DIY/learning, not professional work), I typically have general planning/reference notes in a markdown file synced across my devices via Nextcloud. Separately, for some individual tasks I might have comments about the initial problem, stuff I researched along the way, and the solution I ended up with. Or just thinking out loud, like you mentioned. Sometimes I'll take the effort to edit that info into my main project doc, but for the way I think, it's sometimes more convenient for me to have that kind of info associated with a specific task. When referring to it later, though, it's really handy to be able to use ripgrep (or other search tools) to search everything at once.

To clarify, though, Vikunja doesn't have a built-in feature that exports all task info including comments, just a REST API. It did take a little work to pull all that info together using multiple endpoints (in this case: projects, tasks, views, comments, labels). Here's a small tool I made for that, although it's fairly specific to my own workflow: https://github.com/JWCook/scripts/tree/main/vikunja-export

As long as you only upgrade one major version at a time, it doesn't require putting the server in maintenance mode or using the occ cli.

If not, and you don't want to set up dnsmasq just for Nextcloud over LAN, then DNS-based adblock software like AdGuard Home would be a good option (as in, it would give you more benefit for the amount of time/effort required). With AdGuard, you just add a line under Filters -> DNS rewrites. PiHole can do this as well (it's been awhile since I've used it, but I believe there's a Local DNS settings page).

Otherwise, if you only have a small handful of devices, you could add an entry to /etc/hosts (or equivalent) on each device. Not pretty, but it works.

Some specific things I like about it:

  * Basic todo app features are compatible with CalDAV clients like tasks.org
  * Several ways of organizing tasks: subtasks, tags, projects, subprojects, and custom filters
  * list, table, and kanban views
  * A reasonably clean and performant frontend that isn't cluttered with stuff I don't need (i.e., not Jira)

  * A REST API, which I use to export task summaries and comments to markdown files (to make them searchable along with my other plaintext notes)
  * A 3rd party CLI tool: https://gitlab.com/ce72/vja
  * OIDC integration (currently using it with Keycloak)
  * Easily deployable with docker compose

Off the top of my head, I'm not sure how else you'd visually communicate "this bit is interactive on click/hover but isn't a link." Maybe a different text color (without underline), background color, outline (replaced by the colored highlight bar on hover), or a slightly larger and more distinct icon to replace the generic 'image' icon?

Favorite quote:

"attempting to apply its childlike logic to realistic dynamics can only lead to cognitive dissonance even more mind-melting than hearing Goofy ah-hyuck his way through a discussion of his own atrocities."

* The larger presence of commercial OSS projects setting a tone of "projects here are products to be marketed"

* Social media-like features encouraging popularity contests, curating a personal brand, etc.

* Both of the above leading to more users acting like you owe them something ("you're competing for my attention, right?")

I'm not 100% convinced that those or other GitHub-specific factors are primary causes of maintainer burnout, but I think it's certainly possible.

> giving each of these users a clue that there's something they could be doing to make life easier for the maintainers of the project that they are using for free.

The intersection of these two things is something I've been mulling over lately. In other words, how do we respond to the implicit proposition of "I'm going to pay you $0 and expect the effort and patience of a well-compensated service industry employee"? Putting in the mental energy to deescalate conflicts and be diplomatic with challenging personalities is something I'm willing and able to do... but not for a hobby/unpaid volunteer project!

But then there are many different types of people behind those interactions, including but not limited to:

* Someone who's genuinely a sociopath, or at best an entitled ne'er-do-well who just wants free labor

* Someone in full "socially inept engineer mode," with terse communication that comes across as curt or demanding via text, but are otherwise reasonable if you spend more time talking with them; in their own mind, they're probably just being "direct" or "efficient"

* Someone new to open source etiquette, who doesn't yet know what a good bug report or feature request looks like, but are willing to learn with a little guidance

Sometimes it's hard to tell the difference, and all of those cases can have the same effect of being rather draining, at least in the short term. Longer-term, I've had at least a few cases of someone who seemed like an entitled jerk at first blush, but turned out to be a valuable power user who stays engaged with the project and provides useful feedback. Of course power users come with their own challenges, like wanting to cram every feature under the sun into your project without appreciating the long-term maintenance costs. But at least they're more fun to work with!

On large projects like those, what ratio of community interactions would you say are angry/demanding vs supportive/helpful? And any advice for dealing with the negative ones?

For me, probably less than 5% of interactions on PRs/issues/discussions are negative, but even that small amout sure does have a way of draining one's enthusiasm and motivation!