Improvements to the project's transparency

[rauchg]

This is sort of an umbrella issue to discuss:

• [ ] Issue organization
• [ ] GitHub projects, milestones, goals
• [ ] Minor / major version planning
• [ ] Release schedule
• [ ] Testing methodology

I'd love the input from the community to know what you'd like to see in terms of this goal.

[markozxuu]

I would love to see more supervision for Hyper store. The goal is that developers have a nice place to upload their creations. It would be a good idea to encourage the community to create plugins, improving the documentation : )

[DaneTheory]

My Hyper "wishlist":

• Prioritization of issues, filtered based on contributor's ability/output/specialization with respect to the significance of individual issue in how they affect the platform overall, and then officially "ranked" by "Project Managers". People who may not be able to provide the expertise to fix issues, but are well versed in this community enough to understand the final goal. Could be a special "type" of contributor. I dunno. But integration with Githubs Projects functionality would be absolutely excellent.
• Bring back Slack for Hyper. Keep the context of conversations organized and maintained (i.e. channels for feature requests, current development, issues, failed/successful CI builds, etc.)
• Better documentation for developers covering Hyper's lifecycle, plugin development, etc.
• Improve Hyper CLI to include CMDs useful during development/testing.
• Possibly a Dockerized Hyper container to run integration tests in would be nice.
• And in a perfect world, moving away from the Electron dependency to a more performant native build solution. ReasonML <=> JavaScript inter development via BuckleScript using esy/pesy to output code to Dune for final builds is a newer way of doing things. Check it out.

I get what I'm asking for here is all really what you'd find working in an actual company environment, not so much an open source project. But hey, you asked. I love this project and hope to see it grow into what it should be. Cheers.

(Edit) More things to the wishlist:

• We need to figure out a way to optimize plugins. Anything installed via hyper i <plugin> or added to the plugin array in ~/.hyper.js kills overall performance. My work around so far has been to install plugins/themes to localPlugins then refactor multiple plugin functionality into a single localPlugin. It's the duplication of dependencies in node_modules that really weighs things down.
• During development, please stop Hyper from creating backupv1, backupv2, backupv3, etc in my $HOME directory. Maybe have it to where if the developer wants to use their hyper.js config file, then have the development environment accept an alternative path to read that file from.
• Hyper CLI flag for installing plugins to localPlugins. (i.e. hyper i <plugin> --local)
• Distinction between plugins and themes during install in use. (i.e. running <hyper i knows to install plugins in a plugin folder, be it locally or standard, ands themes in a theme folder). This could be set as a required key:value pair in the package.json of then plugin/theme using validation logic inherit to Hyper. (i.e. in package.json have a hyper key which accepts an object as its value. Within the object, have a key type with the value as a string Hyper parses as plugin or theme. Then while using Hyper, the user can enable/disable plugins and themes using the OS's menu options.)

(Edit again...) The more I think about it, why even have the distinction between localPlugins and plugins. Other than say for development purposes, why not just install all plugins to the user's hyper_plugins folder on their machine?

Is Zeit hiring? Clearly I need to just come on board and take care of implementing features lol.

Thanks!

[MacAhmed]

I have been using Hyper for a while but only recently started keeping an eye on the issues page, just to see if there was anything I could help with. However, it sees like there are a lot of Pull Requests, and Issues that are made but they just sit there -- ignored. Its not that any of the Pull Requests seem to have any issues that are yet to be resolved, or any comments etc.

Some more proactive handling of Pull Requests, as well as Issues could really help. However, at the end of the day, this is also a Open-Source project, and I am happy to contribute in any way that may be helpful, whether that's helping with issues, pull-requests etc, or contributing code.