Let's think about the future of fuwari new/additional features.

[L4Ph]

To get started, we recommend reading the following discussion: #356

I believe fuwari has completed a certain level of feature implementation and is now largely in maintenance mode. (I'm not sure what saicaca thinks, but based on my understanding and what the README suggests, this seems to be the case.)

However, I'm happy to receive pull requests for additional features that I wouldn't have thought of myself. Reading this code is truly enjoyable, and it's also fun to imagine that adding this feature might lead to one more person using it. (It's also good that merging these provides opportunities for maintenance, allowing me to continue my own work.)

That's why, just like all of you, it's easy to imagine feeling quite a bit of doubt or frustration (if not outright anger) about new features not being merged.

Therefore, regarding future new or additional features, if you have thoughts on how everyone is feeling, or ideas like "this is how the repository should be managed," please feel free to join the discussion. This is likely much more constructive than me trying to figure things out on my own.

Continuation of the following PR: #433

[Xeonzilla]

[L4Ph]

This is not about "features to add," but about what action to take in response to "pull requests for additional features."
If there are features you would like to add, please send a pull request or write an issue.

[Xeonzilla]

My misunderstanding, sorry.
Thanks for your great work.

[Xeonzilla]

I believe we should actively accept pull requests from the community, as this can improve the usability of Fuwari. For example, the long-pending comment feature that many people need. saicaca is responsible for the overall design and detail control, and those can be refined slowly once he's back. Merging features first can also reduce his workload. If saicaca finds any of these pull requests inappropriate, they can be reverted — the workload of reviewing code to decide whether to merge it or to roll it back later is roughly the same, in my opinion.

[L4Ph]

I have to say no to this.
First of all, I want to decide whether to incorporate the function after the design and philosophy of saicaca have been solidified and the policy has been decided.
At the very least, I cannot incorporate it into saicaca/main on my own, and most of all, I love the product fuwari, so I don't want to do it.

[Amia33]

I missed this Discussion section totally, should have put my questions here instead of issues.

Maybe we can populate a side repository with Cloudflare Workers support. (such as fuwari-cf)
Why: Cloudflare Workers now have added Static Assets support, allowing both SSG and SSR Astro websites to be hosted.
For now I'm using Cloudflare Workers instead of Vercel and it works perfectly (both in static and on-demand mode).
My prototype repo has changed only 1 line in src folder, enabling 1 on-demand rendered page (/about).

Also I'm kinda stuck on adding password protection support, wishing this step can help me later.

[L4Ph]

Yes, since I'm using SSG, I understand that it is possible to deploy using Static Assets on Cloudflare Workers, Cloudflare Pages, Netlify, or Cloud Run.

For SSR, we were planning to add adapter options to support deployments other than Vercel, but fortunately the default deliverable for this repository is SSG, so we think the most we can do is provide a link to the documentation (and Astro's documentation covers that, so we don't see much reason for us to do so).

[Amia33]

Yes, since I'm using SSG, I understand that it is possible to deploy using Static Assets on Cloudflare Workers, Cloudflare Pages, Netlify, or Cloud Run.

For SSR, we were planning to add adapter options to support deployments other than Vercel, but fortunately the default deliverable for this repository is SSG, so we think the most we can do is provide a link to the documentation (and Astro's documentation covers that, so we don't see much reason for us to do so).

Yeah the documents are quite available around and another repo seems unnecessary...
Actually I propose to add a dev branch to make new features/improvements somehow official (rather than cherry-picking those PRs on one's own).
This should be much better than what I originally thought

[L4Ph]

I don't think it's a bad idea to create a branch and work on it separately from the main version, but in any case, an impact merge to the main version will occur, so I'm not sure what to do.

[Amia33]

I don't think it's a bad idea to create a branch and work on it separately from the main version, but in any case, an impact merge to the main version will occur, so I'm not sure what to do.

I think we can make following steps:

1. Force all PRs from outside to dev branch (which can be specified)
   For example, dependabot has target-branch setting, make it possible to track updates only on dev branch
2. Directly cherry-pick those merged PRs into main branch if it's minor change/dependency update, or make a subsequent PR to wait for further action.
3. (Optional) Edit code on main branch to make it only as a template, not handling adapter, etc.

This procedure can also work after the owner comes back, as it makes main branch more robust.
(Let dev branch users test before a commit/PR actually goes into main branch)
I think the owner can accept this.

Backup: If most PRs during this period were reverted, we then make a fork and work on that.

[pawarherschel]

I recently added open graph images to my blog, is there any interest in adding those?

I'm using https://github.com/typst/typst (an alternative to LaTeX) to generate the svg and converting it to png using resvg.

I have more experience with Typst so it's easier for me to debug the output + I can iterate faster compared to debugging satori.