vevy wrote: ↑Sat Oct 17, 2020 12:48 pm
What I mean about filters:
- Something like this.
- The ability to filter (only show) tools with (for example) size below 5M, open-source license that allow you to convert csv or compress pdf, etc.
- The idea is to also be able to filter by any other criteria like release date, current/discontinued, ported tool or native Windows, TUI or regular CLI, etc.
Honestly, your filters don't sound that useful to someone who is looking for a CLI tool.
For size,
filtering by size wouldn't be useful. You'd rather find the
smallest tool which meets your needs, not ones which fall below an arbitrary threshold.
Open source license would be a plus but usually not a requirement for a user. If the tool is free and does what you want, it's usually enough.
Release date and current/discontinued are potentially useful, but maybe not so for CLI tools. CLI tools are usually quite mature and don't really need updates.
Ported tool or native Windows: why would you care about that?
TUI vs CLI: those two UI paradigms are usually encountered with completely different tools. You rarely find cases where you can do the same thing with multiple programs, some of which are TUI and some CLI. (TUI is a much better fit to, say, text editors like
nano.)
As such,
I'm siding with Andrew here. Filtering functionality would take effort to implement and be of little use.
webfork wrote: ↑Sat Oct 17, 2020 3:41 pm
Agile often fails to build smart frameworks and just becomes a bag of disconnect features, where Waterfall projects sometimes get shelved after two years when the technology changes or the project runs out of money.
Agile projects often do much better than you envision here.
The primary point of agile is to involve the client with development of the software. (Both models are primarily designed for the situation where a software shop develops something for internal use of their client.) The point is that once the client sees what the software is like in practice, they can better identify what they actually want and steer development to the right direction.
As a concrete example,
Angry Birds Stella was developed with agile style and I was one of its programmers. The original plans called for shooting the birds with a swing instead of a slingshot: however, when we tried it in practice, we found that it didn't work as well as the traditional slingshot and we scrapped the idea. If we had used the waterfall model instead, we'd have instead stuck with the original plan and made the game worse. (In the end it didn't matter because the game was financially a failure anyway. ¯\_(ツ)_/¯)
There is nothing that would inherently make an agile project "a bag of disconnect features".
Waterfall projects indeed have a risk of getting shelved in a late stage. One of the problems of the waterfall model is that you need to finish the entire project before you deliver anything. If the money runs out before that, tough luck.
webfork wrote: ↑Sat Oct 17, 2020 3:41 pm
Is it possible to do something iterative (more Agile), meaning you have a few filters and then see how people use it, or even come back later and try to add more or do something more complex (akin to Waterfall)? Maybe focus on building up the database and working within available tools, addressing more complex analysis tools down the road?
This is more for Andrew to answer, but from what I can tell, filters can indeed be added incrementally. Being able to filter by one criterion requires that there is a DB field for that criterion (e.g. for size, the existing size field can be used), UI to allow maintainers of the DB to edit it and search UI. The actual filtering would merely require adding another criterion to the SQL statement. It's the UI which is the highest amount of work.