Collaboration

[wobbol]

Let the discussion about who would like to contribute and how much access each contributer has to this org.
for example "who else would like the ability to add new members to the org?"

Also, introductions and the area each collaborator would like to work on.

Wobbol:
IAMA random person who has an ErgoDox who was slightly disappointed that the ErgoDox community had no special org just for them.
I haven't much looked at the code since I have been here, 90% of my concern right now is the documentation. I would like to build a better software ecosystem around the ErgoDox with client side applications with the goal of bringing our users the best possible experience the Internet has to offer for keyboard configuration.

@marknsikora
@squarefrog
@ErgoDox/ergodox-maintainers

[marknsikora]

Well I guess we need to have some discussion here then about what the future is going to look like. Right now we have 3 areas that are seeing development here, squarefrog/tmk_ergodox, and the original cub-uanic/tmk_keyboard. I had stuck with putting everything under the original repo since that is where all external sources point to including the tmk/tmk repo. The future of tmk seems to be the new tmk_core repo so we're probably going to have to make a new area to work in, so this is as good a place as any.

Me:
Electrical engineer with a focus on hardware. I've read through most of the tmk_core and all of the ergodox source. I'm mostly interested in improving the code quality and integrating new features from tmk into the ergodox setup (eg. new hook support). I sort of became the defacto maintainer after cub-uanic left. I've already put a good deal of work into getting things into better shape (see cub-uanic/tmk_keyboard#34). I would prefer to be an owner of the group as well since I plan on sticking around for quite a while and don't want to get locked out in case @wobbol leaves.

P.S. minor gripe with the naming. I would prefer if this repo went with the tmk_ergodox name. In the future I plan on making a qmk_ergodox repo unless tmk gets support for more bytes in the keymap. Also there is also an ergodox repo out there with all the design files for the board.

[wobbol]

Done and done. It took me a second to find the option.
I have no attachment to the name so, I just changed it per your reasons. I don't see myself being away for more than a few days, but I do appreciate the stability that another owner brings to a project.

[squarefrog]

Ok I'm a mobile software engineer, and I've been using the ErgoDox for a couple of years now. About a year of that being cubs fork. I also really appreciate clean safe code, which is why I originally created my new start branch. I don't do a lot of low level C, other than a few Teensy/Arduino projects, and when I have to drop to C APIs in iOS, but I know just enough to be dangerous 🔥 🚒

Looking through a few of the old pull requests and issues, I think one of the number one issues people had with contributing was not knowing how to contribute to the project. This might be a lack of git knowledge or whatever.

I agree better documentation would be the first step. It would also make sense to come up with a layout strategy. I like the idea of a vanilla layout for the top layouts, that make it quick and easy for someone to hit the ground running. However, I don't want to end up in the same situation as qmk where there are dozens of duplicate layouts with minor tweaks.

Further down the line a GUI tool which would allow people to experiment with the fork without having to understand C arrays would be helpful, although there was a Node app not so long ago (vi keys?), which might be a good starting point.

I do think the best thing for the community in general would be for any documentation improvements to also be passed onto tmk. There's a hell of a lot we can do with forks now, but the documentation leaves a bit to be desired. Even with a knowledge of programming, it can be difficult to figure out.

[wobbol]

Maybe writing good issues for contributers to handle would be a thing to do, I think it could go like this:
One of us makes an issue like "There are no GUI apps for tmk config, link us some!"
Then, after the issue sits like maybe 2 weeks, if no one has done the issue we can just do it.
Another thing that might really help people who want to contribute, but don't feel comfortable jumping into an issue is, having an irc or mailing list presence.

Maybe we keep the 4 layouts we have now and accept new ones for other languages, but any layout tweaking contributions, if deemed worthy, could be separated into its KEYMAP() constituents and stored in a properly labeled subdir.

What bit of our documentation is relevant to tmk_keyboard or tmk_core?
A good list of the keycodes avalable in .md form.
How to implement new keyboards?
deprecated ways of interacting with tmk_core?
@marknsikora would probably know more about what kind of stuff we can give back upstream.

This is kind of a tangent but, I think there is value in giving the user a choice between terse and condensed or hand-holding and visual. Maybe the first thing would be best shown with just a list of shell commands that "Jack 'The Teensy Hacker' Smith" did to go from zero to testing. Then the second thing could be the ideal way "Chloe 'The Writer' Jones" installs software.

Then maybe have the same kind of choice in the contributer section? idk it sounds like a lot of work to write and maintain, depending on how often the information changes.

[marknsikora]

irc or mailing list presence

I think we're way too small to justify the effort involved with that.

@marknsikora would probably know more about what kind of stuff we can give back upstream.

The tmk docs are very dense and technical. They're written for people developing with tmk so I don't imagine a lot of user focused docs getting merged. For example the keycode idea you listed would probably get rejected since it's all in a single header file and also having it in a md file would create redundancy and a maintenance burden.

[wobbol]

When I get some time this weekend, I'll see if I can pull the important bits from everyones opinion and put it in a doc. I think it maybe should read somewhat like a mission statement, but without the pretentious air of a "mission statement". I'll do it in a PR so, you two can give feedback before it gets merged into master.

[wobbol]

it seems clear that i will be doing this alone. no need for collab stuff other than this repo.