Skip to content
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

order of Projects Using Quasar #42

Open
mesqueeb opened this issue Jul 13, 2018 · 9 comments
Open

order of Projects Using Quasar #42

mesqueeb opened this issue Jul 13, 2018 · 9 comments

Comments

@mesqueeb
Copy link
Contributor

To prevent any hierarchy issues in the future I suggest an alphabetic order for 'Projects Using Quasar'.

Or an order by Quasar version (newest most top), and alphabetic sub order; this will also motivate people to update their apps to the latest versions.

@janne-rantala
Copy link
Contributor

I suggest the second option: order by time desc, name asc

@mesqueeb
Copy link
Contributor Author

Yeah anyway my point is I think it's better to see newer projects (and with newer versions) on top of the file.

First in the list stays on top is not a good method for such a list from the consumer point of view. Only for the submitter.

@awulkan
Copy link

awulkan commented Dec 21, 2019

I agree that it would be nice to see projects with the newest Quasar version first, but that also means that this repository will have to be updated every time someone upgrades their quasar version.

@mesqueeb
Copy link
Contributor Author

@awulkan not at all. They can PR themselves.

@awulkan
Copy link

awulkan commented Dec 21, 2019

@mesqueeb that's what I mean. You'd get a PR every time someone migrates to a new patch version of the framework. And if you don't merge them fast enough there will be conflicts since everyone is constantly moving their project to the top of the list.

@mesqueeb
Copy link
Contributor Author

mesqueeb commented Dec 21, 2019

@awulkan that's the kind of market we live in. the people who are willing to put in the effort to update their websites and then come all the way here to create a PR that moves their package up top should be rewarded.

For the maintainers of this repo it's just clicking merge. And perhaps sometimes check if the said website really uses the version. Perhaps require them to be able to check it in the shared repo, not allow this action when there is no open source repo.

Otherwise we are not promoting the devs to keep their websites up to date at all. I think to have a healthy ecosystem we should always promote to keep their apps and websites up to date and reward them by being able to move their project to the top of this list if they want and bother to actually come back here and make the PR.

@mesqueeb
Copy link
Contributor Author

Another point I want to raise:

If consumers/devs who never used Quasar come here, I think most human beings tend to:

  1. open a few links starting from the top (this is what Google taught us)
  2. see just a few of those crappy websites with ancient quasar versions

No personal attacks, but ancient Quasar versions had more bugs and were slower.

I think this will have a bad impact on people's decision wether or not to start using Quasar.

The latest versions are just so much more representative. They should be on top.


If you still don't like this and think you'll get too many PRs, how about this:
Just make people always PR for them to be on top, but you can only PR once per project.

So once you decide you want to be on the list, your position will be on top, but going forward other newer websites and apps might come above it.

This is really good because you can decide: when is a good time to make the PR here. You'll get the marketing but you know you'll only be able to get it once.

This automatically keeps "newer" versions on top, regardless of the actual version.

@mesqueeb
Copy link
Contributor Author

What if Google said: "oldest websites first, newer last"
Then we'd still get websites made in 1990 when searching things, and have to go to page 9999999 to get relevant results. 🤣

@awulkan
Copy link

awulkan commented Dec 21, 2019

I'm not saying it's a bad idea to have the newest versions on the top, I'm just wondering if it's feasible to merge in loads of PRs (potentially) every time Quasar releases a new patch version.
If the maintainers have no issue with it then fine, do it.

I also think that dead links should be removed periodically.

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

3 participants