Roadmap

[squarefrog]

I think it would be a good idea to establish some sort of road map to limit duplication of work here. It would be good to get this fork to a state where it's easy for other contributors to help out.

Here's what I foresee as the priority of updates for the near future:

• [x] Assess outstanding Pull Requests, and close or merge as needed
• [ ] Get a basic layout option together for each of the main layouts (QWERTY, Dvorak, Colemak, Workman)
• [x] Rework the default keymap to follow Ben Blazek's model.
• [x] Match the new keymap define method, and default to the reworked QWERTY
• [ ] Make the Makefile.lufa default, rename to Makefile, and recommend that that should be the one to use unless Makefile.pjrc is something that is really needed
• [ ] Refactor the fork to include tmk_core as a submodule, and move the Ergodox specific files to the root of the project
• [ ] Create a docs/ directory with the current FAQ file, or move to Wiki.
• [ ] Replace the current README with basic git and build instructions to make it much easier for newcomers to dive right in

I'm open to suggestions for anything else we've missed here. I'm happy to split up the work with @marknsikora to sprint to get this list done.

[marknsikora]

I agree with most of what's here. But I guess one thing to discuss is the issue of how to handle the move to tmk_core. The main issue I see with keeping the current repo is the name. As you pointed out earlier one of the repos using the new scheme is called BenBergman/bluetooth_kinesis. And I imagine we would want to end up with something like tmk_ergodox for ourselves (to help differentiate us from the other ergodox firmware).

[squarefrog]

The way I see it there are some pros and cons to keeping the current repo as is.

Pro

• Keep the full git history, and keep it visible as a fork of tmk
• Keep project visibility: a google search for 'ergodox tmk' results in several geekhack and deskthority threads linking directly here
• The project is already linked in the tmk readme

Con

• It's harder to differentiate that this Ergodox specific
• Doesn't represent a change in 'ownership'
• Renaming this repo would have to be done by cub in order to get the automatic GitHub link forwarding to work
• After changing to tmk_core it would require manual intervention from anyone who has forked this repo to add their own layout. For example, they would need to move their specific header files to the root, and include them in the Makefile.

Keeping the git history is possible providing someone pushes a local copy of this repo to a new repository, but that would distance itself as a fork, which is no bad thing. I personally think the right thing to do when moving to core is separation, but I do feel that the move should be the last thing we tackle as there are a few outstanding Pull Requests based on the current structure.

[marknsikora]

I ran across this repo which may serve as a useful base if we choose to go the submodule route https://github.com/fredizzimo/infinity_ergodox

[squarefrog]

I've actually done it :

https://github.com/squarefrog/tmk_ergodox

It's really simple and elegant.

• Create new git repo
• Add tmk_core as a submodule
• Move the project files from /keyboard/ergodox To the root dir
• Edit the location of the core on the Makefile

[squarefrog]

The only thing I am missing is https://github.com/cub-uanic/tmk_keyboard/pull/23

I'd do a pull request on tmk_core but it's very unlikely that it'll get merged.

I kind of wish QMK went the same route so it'd be easy to try it in a branch. I don't really want to go back to the old project structure.

[marknsikora]

@squarefrog it looks like dev is moving over to the ErgoDox group, can you add me to that group so I can continue my work there

[squarefrog]

@marknsikora I can't as I'm not an owner of that repo. Ask @wobbol

[wobbol]

Yea sure @marknsikora, it's no problem. Actually, Ive already sent you an invitation.