Skip to content

Note on feature requests #192

@one-kash

Description

@one-kash

Hey folks,

I read every issue that comes in - the ideas, the bug reports, the back-and-forth. All of that shapes the app. The volume has gotten past what I can keep up with solo, so here's a note on how I'm handling feature requests from here on.

KashCal is a side project. No company behind it, just me, evenings and weekends. Rather than silently let things pile up, I want to be honest about where requests are going to land.

I'll be saying "no" or "not now" more often. Usually when:

  • there's already a way to do the thing, even if not the version you'd prefer
  • the request solves one case but makes the app heavier for everyone else
  • it pushes KashCal in a direction I don't want it to go
  • the reason is "app X has this feature": every calendar app is making different tradeoffs

Bugs, crashes, sync issues, and accessibility problems stay at the top of the queue. Those aren't going anywhere.

For what I'm actually working on right now, see the "pinned Current Focus"

Thanks for using KashCal.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions