Hi Be, On Thu, Nov 19, 2015 at 6:16 PM, Be <b...@gmx.com> wrote:
> 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. I'm totally with you -- but I think we have to acknowledge that some people don't care that much about Mixxx (say it ain't so!). They got their preset working and had just enough try-hard left to post about it on the forums. This is ultimately a trade-off curve between mapping coverage and quality. So far we've skewed more towards coverage. I agree that once the project has grown to a certain size we will have the luxury of rejecting contributions but as far as I'm concerned, the biggest problem we have (which is backed up by data we collect in our yearly surveys) is lack of support for devices. (not that we ship a broken mapping -- we just simply don't have a mapping) So -- to re-summarize my position -- for people who are closer to developer on the side of the spectrum and have the willingness to give up some time to get the tools installed, learn how to use them, obey our spec as published, and then go through a few rounds of code review -- I think that's great! If we get enough of those people involved then our device support would be in great shape. We could create a new class of preset "Community Gold Presets" which are those maintained on GitHub that have a test suite and pass Mixxx's preset guidelines to incentivize it and maybe give out badges or send people stickers/tshirts in the mail or something like that. But I think we're not yet in the position to have the luxury of turning away mappings that are shared and reported by a few users to work but don't happen to be high in code quality. Usually it's hard enough to get people to fill out the <metadata> section with contact info, a Wiki and forum ink (which I usually do ask people if they're up for doing but I do it myself if they are not). > Who knows if they work with current versions? We take a lot of care on the C++-side to not break backwards compatibility. I'm quite stern about this. Not that it doesn't happen in some cases. > 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. Given that you can create and export a working preset with nothing but the Mixxx GUI-- I'm going to have to call BS on this. :) It's hard to put yourself back in the beginner mindset -- but Git is really freaking hard to use! Take Sean for example (sorry Sean). When we switched to git it became a major obstacle to him contributing and he's a core developer who's been around for many years. He's only just now (as in this week) learning it! Also -- understood that the plans aren't done yet -- but JSHint and other tools require Node -- which a whole other set of skills you're requiring (and thereby losing people to). > 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. Providing a nice library sounds great! And building an easier to use mapping system would also be great. I'm really thankful you're working to improve things here. Best regards, RJ > > 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
