Flow/Neos Package Listing

#1

Topic to collect ideas about a Flow/Neos package listing to make finding helpful stuff easier. What would you expect from such a listing. I think we should start with something easy and simple as that will already help a lot but then implement ideas from here one by one.

Generally:

  • searchable
  • ideally automatic (using package metadata)
  • list dependencies?
  • ratings?
  • comments?

More (future) ideas:

  • available versions
  • showing README.MD?
  • using package metadata to show list of maintainers, links etc.
  • search filters
  • tagging
1 Like
#2

Maybe the comments can be based on Discourses, see:

#3

Tim started working on this a long time ago, could be used as a basis to build on. https://github.com/timkandel/TimKandel.PackagistFE

Christopher and I talked about making this independent of the website to avoid a similar situation where upgrading the website becomes a huge task due to all of it’s components. And seeing as this can easily lived on a separate sub domain and be integrated into the website instead, I would suggest we keep it independent.

Also keep it simple for the first iteration as long as we keep the further plans in mind so we don’t make achieving them harder down the road.

I think we should allow for pictures to display what the package does in a easier comprehensible way. Sure it doesn’t make sense for not all packages to provide such material, but for those that do it’s a big advantage.

Additional ideas:

  • Downloads counts
  • Supported languages
  • Categories
  • Link to repository / packagist
  • Filter by author
  • Featured packages
1 Like
#4

Could be great if we could highlight top-quality packages somehow (maintained or reviewed by team members?)
Always hated TER for being pool of poo… Less is more.

#5

+1 for some rule around curating good extension, but it’s hard to have nice rule and not arbitrary things, I’m a team member, but lots of my package are not handled correctly (support, maintenance, …) … so team member is not the only point here.

+1 for subdomains, one subdomain / site per main task (packages, documentation, funding, …) Let’s use Neos as a multi site CMS :wink: and push this feature set to their limit.

#6

Super duper idea!

+1 for making it independent from the site. We should use microservices approach and this one seems to be an ideal candidate for that (i.e. separate Docker image for that service)

+1 for some quality system. Maybe at the beginning some sort of voting would do (as Christian mentioned)? Something similar what StackOverflow uses for answers/questions.

Automated listing: I think one should come here and register own (or sb else) package if it’s supposed to be listed here. Packagist, Bower have the same approach, just having package.json/bower.json doesn’t mean it’ll be listed on their sites.

I’m sure we can get some inspirations from e.g. Chrome Web Store (Aske already listed couple of these): images, voting, comments, showing README, tell the developer (an/or link to issue tracker on GH), support status, category etc.

#7

There was a little discussion on Slack today about Typoscript Snippets Listing. Could/shall we include such a functionality in this project ?

The reason for that is is that plenty of mentioned above functionalities could be shared in snippets directory, namely categories, voting, comments etc.

Links:
http://typo3.org/documentation/snippets/
https://fluidtypo3.org/library/code-examples.html

Official code sharing platform (snippets)
#8

I recently thought about using Gists as the base for Snippets, and just have a site where you can post Gist URLs and tag / search them. So I don’t really see that as a part of the package listing. I’d rather want to have lean and small tools / apps that are connected (REST APIs) where it makes sense. “Focus on one thing and do it well” :wink:

2 Likes
Official code sharing platform (snippets)
#9

technically it doesn’t have to be a subdomain though - we can also split up to different servers / Neos instances with a sub path. But for us maintaining the site, that can a be a little bit more work and confusing.

What I’d like to avoid though is that we have dozens of sub sites which differ in design and you start trying to find out where to find what.

#10

Indeed a “staff pick” label would be helpful. We just have to define a guideline for picking those, but it should be fairly easy to manage since it’s about the quality of the code, documentation, versioning policy and being maintained actively. The label can always be withdrawn again.

In addition to that we should definitely have something like Githubs star system.

#11

The point was more about keeping the code separately, if we can improve the user experience using paths instead of subdomains that’s all good :smile:

And +1 to avoid them not looking in sync, I’ll keep this in mind when we redesign the website to have reusable styled components that we can use for multiple websites.

#12

Thanks for mentioning it here, but I agree with Christopher it’s should be separate.

Hence I started Official code sharing platform (snippets)

#13

Replied to the gist stuff here Official code sharing platform (snippets)

#14

I recently stumbled upon a site listing all kinds of Ember CLI packages that could be an inspiration for a future Flow / Neos package listing: http://emberobserver.com/

They have some good ideas on how to rate packages and how you can use a badge on your (Github) repo linking back to the listing (e.g. https://github.com/samselikoff/ember-cli-mirage).

Might be worth to have a look at some of their concepts.