Matt's Dev Log

This is to test Pherephone, the latest ActivityPub project from Write.as.

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

I'm thinking we should bring our various command-line importers (e.g. the text importer and wf-migrate tool) into the main CLI. This fits in line with the file-syncing features we're going to eventually add to the CLI, and enables us to take advantage of certain shared, required features like account authentication. We could even leverage the existing CLI UI for things like choosing which collection to import posts to.

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

Many of the changes I make are small, quick fixes in response to users — some recent cases are #137 Prevent transliterated slugs exceeding length limit and #138 Don't consider post unpublished when title exists.

They're often quick fixes, taking no more than 10 minutes to fix. I usually deploy them on Write.as once they're done and I've verified the fix. I know the software well enough to feel confident deploying new code so quickly, but of course, there are always blind spots.

So I'm going to start making these small changes with pull requests, instead of committing directly to develop. This puts them on the same field as everyone else, and gives everyone visibility into what's going into the codebase (remember, you can watch the GitHub repo to get these notifications, or follow @writeas_dev@abunchtell.com in the fediverse).

This is the main reason I'd like to do it this way — to notify everyone and provide a comment period, rather than a formal code review like we do with larger features.

I'm going to leave these pull requests open for a week, and then merge if no one brings up any issues. If it turns out that the change caused some kind of regression, etc., we can fix it and reference the original pull request.

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

• Update documentation
  • Tag release in documentation repo
• Deploy changes to the Getting Started guide on WriteFreely.org
• Tag release in writefreely repo
• Run make release in the writefreely repo
• Finish writing changelog in pad
• Compile the GitHub release
  • Paste the changelog into GitHub
  • Upload the binaries
  • Publish release
• Paste the changelog into Write.as
  • Add links to issues
  • Write extra introduction
  • Link to GitHub release
  • Publish blog post
• Deploy Write.as for Teams application
• Upgrade WriteFreely.host instances
• Boost blog post on Mastodon

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

Now that we're growing past one core developer, we've moved #WriteFreely development off of master. As I mentioned on Mastodon:

Things are validated. Now all core development is done on feature branches off of develop, with code review before merging. (So, more validated than the master branch used to be.)

Of course, there may be some larger features that get added over several pull requests (thus might need fixes / changes), but in general we're trying to avoid that.

https://writing.exchange/@matt/102253459016412908

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

With a growing team of core #WriteFreely developers (#wfdevelopers), we're starting to document everything needed to actually work on the application. It'll be a long process, but it's underway.

Official documentation lives in Markdown files in the writefreely/documentation repo. Current work is done on the develop branch (contributions welcome).

Most recent addition, thanks to @sandrockcstm: an explanation of the database schema

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

I got the number of open issues on WriteFreely down below 10 again today, after reaching its high of 13. After some time maintaining this project, I think keeping this number low is actually kind of important.

• We tell everyone that Github is only for reporting bugs, and that we're very responsive there. Keeping this number low backs this up.
• A low number of issues makes it easy for others to find bugs they might've encountered, as well.
• Keeping this number low signals that the project is active and moving forward.

For a #FOSS project like ours, with a strong vision / direction to follow and core developers pushing that forward, I'm finding this setup really works well for us. We gather input on our forum, turn that into long-term plans in Phabricator, and adjust to real world usage on the platform that's closest to it all, Github.

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

Here's how you might create a new page for users in WriteFreely.

In this example, assume you want to create a new Import page based on the current Export page template:

• create a copy of templates/user/export.tmpl named templates/user/import.tmpl
• change define "export" on the first line to define "import" (the name here should match the filename between templates/user/ and .tmpl
• duplicate the viewExportOptions() handler func in account.go, changing it accordingly
• add the import page route in routes.go

#WriteFreely #wfdevelopers

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.

Single-user issues so far:

• “Public” option shows on blog Customize page (should never be there in this mode)
• Pinning a post links to /matt/about instead of /about
• Instance-level About page shows at the bottom of user pages (should never show in this mode)
• Drafts page shows “Find your blog posts from the Blogs page.” (should never show in this mode)

---

Get future updates via RSS and ActivityPub: @devlog@matt.writefreely.dev.