Skip to content

I would like to contribute, a "vision", "goals", "philosophy", "principles" document might help #1372

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Weyaaron opened this issue Feb 20, 2025 · 3 comments

Comments

@Weyaaron
Copy link

Hi all,

I have read the post on reddit that called for contribution/maintainers. And I would love to participate,
this is my first actual comment on this repo.

I have started following the issues and have read through some of the backlog. My impression is that there is no "clear" written document that expresses what this project is about. There are these 3 bullet points in the Readme, but this is not something that helps with deciding which features to include. Maybe the maintainers/we (As in, I would like to participate but do not feel confident dictating something) could write something up. There is even some potential to include it in the issue templates. That would encourages users that suggest new features to confirm that their suggestion follows these principles. This would ease maintenance by filtering some of these suggestions/providing guidelines for their acceptance.

If there is some consensus that this would be useful, I will happily help out with the creation.

Looking forward to helping out,
Aaron

@josephburgess
Copy link

Likewise - keen to contribute!

If I could take a stab at part of the 'philosophy' (without treading on anyone's toes, and like @Weyaaron above not wanting to dictate anything) I guess there's a few key points that seem to come to mind:

  • Minimalism – It is a starting point, not a distro. Just enough features to get started, no bloat.
  • Readability – Every line of code should be easy to understand, modify, and extend, remembering that many users may be complete beginners in lua.
  • Encouraged customisation – users are expected to fork and begin to become addicted to editing their config - it should be fun and easy to get started

Should there perhaps be some accompanying documentation somewhere, outside of the init.lua comments, outlining the rationale for each plugin choice along with a few links to alternatives and the pros/cons to consider if switching?

That might get people used to the idea of thinking about the factors that matter to them.

in terms of the plugins themselves I guess when people suggest new additions, they should:

  • be widely adopted, well maintained/documented and be the bare minimum to get an 'ide' like setup
  • require minimal configuration to work out of the box with good defaults - BUT importantly - should be easily customisable
  • not lock users into a specific workflow or ecosystem, perhaps avoiding 'all-in-one' plugins
    • I think the mini.nvim plugins are perhaps the exception to this rule - (for me at least) I think they are a great intro for a beginner figuring out customisation
    • They also work really well as individual/standalone features not dependent on each other if the users begin to look elsewhere to replace one or more of them
  • Not duplicate functionality of an existing plugin, if it does then there needs to be a rationale for why the old one should be replaced

@rfletchr
Copy link
Contributor

It would also be worth defining a scope of what sort of features you intend to include.

  • Plugins
  • LSP and Completions
  • Formatting
  • Searching

I think the core set of features TJ targeted are pretty comprehensive, going beyond those would to my mind devalue the config.

Once you read kickstart its easy to add other capabilities as it give you the tools to fish.

@feoh
Copy link
Collaborator

feoh commented Apr 9, 2025

I like the idea of Minimalism but feel like the current kickstart is VERY far away from that.

I'm fine with evolving it in that direction if the community feels strongly about it but that would involve people actually authoring PRs that would reduce bloat without foot-gunning new users :)

If you feel strongly about this, please take this opportunity to help me decide between blink and 'native' completion by chiming in on this PR in favor if choosing that approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants