I'm concerned about having mapping developers not be involved in the development workflow. How can we expect mappings to be maintained and keep up with new features in Mixxx if they aren't? Moreover, how can we expect them to be documented? There are many undocumented mappings included in Mixxx that were made for versions that are now very old. Who knows if they work with current versions? They certainly don't use new features. Who knows how they work if they are not documented? Who knows if they're even complete? Users should be able to easily tell before they buy a controller how it will work with Mixxx so they can make an informed decision about what to get.
Cloning a git repo, committing two files, writing a wiki page, and opening a pull request is not a high bar. IMO it is lower than the bar required to write a mapping. I think your concern is nothing to be worried about considering all the high quality mappings that have been merged recently since I started improving the documentation. If this leaves out some low quality/incomplete mappings, IMO that is good. When a mapping is included in Mixxx, that gives the impression that it works well with Mixxx and spending money on that device is a wise decision. I doubt many people who buy a device with the intention of using it with Mixxx that find that it doesn't actually work well are going to continue using or contributing to Mixxx. I think including bad mappings is worse than not including anything. I think what really excludes a large portion of the user base from contributing is the clunkiness of the mapping system and the lack of guidelines. So far, every mapping author has figured out their own way of doing things, which has resulted in a lot of unnecessarily duplicated work. Most mapping authors are not JavaScript experts and only know the mapping system well enough to get by, so the approaches they have taken are of varying quality/readability/maintainability. Hence, why I will start a JS library to make mapping easier and more intuitive. On 11/19/2015 07:36 PM, RJ Ryan wrote: > Hi Be / Tuukka, > > Sorry for missing this discussion. This is a great topic to have > guidelines around. > > I'm concerned about expecting the preset contributor to be involved in > our development workflow (Git, GitHub). This is a high bar that's going > to exclude a large portion of our user base from participating. > > The way we have functioned for years now is that users post presets on > our forums and we do some legwork to bundle them with Mixxx if they > aren't sending us merge requests directly. I don't think we should stop > that but instead (and what I have been doing for quite some time) is > engage the preset developer and ask them to submit PRs -- but if that > isn't an option for them or they aren't interested, regularly sync their > version from them on the forums to the codebase. > > If there is an existing preset then we usually check that a couple of > forum users confirm it works well. If it diverges significantly from the > original preset functionality then we might stick it in alongside the > existing one. > > In particular, > https://github.com/mixxxdj/mixxx/pull/780 > seemed fine to me. Multiple forum users confirmed it was a valuable > addition to the existing preset so it's pretty normal for us to include. > > Thanks, > RJ > > > > > > On Mon, Nov 16, 2015 at 3:22 AM, Tuukka Pasanen > <pasanen.tuu...@gmail.com <mailto:pasanen.tuu...@gmail.com>> wrote: > > Hello, > GIT would be best solution but probably will fail the reason you > mentioned.. should we use pages talk-version as new stuff incubator and > then add it to main page? > > Tuukka > > 13.11.2015, 09:06, Be kirjoitti: > > Interesting idea, but I'm concerned that requiring people to do more > > work to update the wiki would keep people away from contributing to > > the wiki more. > > > > On 11/13/2015 01:01 AM, Tuukka Pasanen wrote: > >> Hello, > >> Dokuwiki also have markdown support with plugin so should we have > >> 'original' in github as rst-file (If we like translations also). Then > we > >> could have these as base for Dokuwiki then use normal Pull Requests to > >> update those. Little bit double effort but as Be said more qualified > >> documentation but can be automated with script? Because how many edits > >> regular Dokuwiki than Be? Because without good documentation > application > >> like Mixxx is unusable and it won't conquer world. > >> > >> Thanks, > >> Tuukka > >> > > > > ------------------------------------------------------------------------------ > Presto, an open source distributed SQL query engine for big data, > initially > developed by Facebook, enables you to easily query your data on > Hadoop in a > more interactive manner. Teradata is also now providing full enterprise > support for Presto. Download a free open source copy now. > http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > <mailto:Mixxx-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > ------------------------------------------------------------------------------ _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
