On 11/19/2015 08:47 PM, RJ Ryan wrote: > Hi Be, > > On Thu, Nov 19, 2015 at 6:16 PM, Be <b...@gmx.com <mailto: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.
There isn't much of a trade off. In the last couple of months, since I have been asking everyone who posts a completed mapping on the forum to submit a pull request, I only recall one person who declined to do so. That was for a little-known device that frankly I'm not too concerned about (http://mixxx.org/forums/viewtopic.php?f=7&t=7448 ). If someone put the effort into making a mapping and sharing it with the world online, they're usually interested enough to open a pull request and have it reviewed. I think you've mistaken people's confusion because of the lack of documentation and guidance for laziness. Make it easy to contribute, and contributors will come. That does not mean quality has to suffer. This has already been happening the last couple months. > 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) How do you know that they don't consider broken mappings as an unsupported device? Where are the results of these surveys and who participates in them? Are you only thinking about current users? What about users who might use Mixxx if it worked with their hardware? If I spent hundreds of dollars on a device that was supposedly supported by software but was really only kinda supported, I'd consider it effectively unsupported and be frustrated. I think most people in that situation would forget about Mixxx and just use the proprietary software the controller was designed for. Also, what devices do people want supported? IMO it is a big problem that Mixxx lacks much support for popular brands that make quality hardware that is commercially available today. ~3/4 mappings in Mixxx are for devices that have been discontinued. Where is the support for contemporary Native Instruments, Pioneer, Akai, and DJ Tech Tools controllers? Write the documentation, and people step up to do the work. The HID mapping system is still undocumented years after it was implemented (Sean mentioned he could write documentation for it on IRC last night). Source code is not documentation. > 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 > do it myself if they are not). To summarize my position, there is no point to including dubious quality mappings in Mixxx. Users can go search the forum for those. Being included in Mixxx should be an indication that the controller can actually be used well with Mixxx. > 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. :) Given that you can't actually use that to make a fully (or even close to fully) functioning mapping for most controllers available today and would have to rewrite it in JS anyway, I'm calling BS on that. > > 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! I was just in the beginner mindset a couple months ago. I'm doing all this because I remember how difficult it was to decide on a controller to get and then map it. The biggest obstacle to mapping was the lack of guidance and good examples to understand how to write a good mapping. So I used what I figured out to write examples to the best of my ability and edited the language on the wiki. I have since learned quite a lot more about Javascript thanks to Tuukka's insistence on using JSHint and will use that knowledge in developing the library. > 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 agree that Node.js shouldn't be strictly required. But reviewers can run it through tools that require Node and code can easily be copy and pasted onto web-based tools. > 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> > <mailto: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> > <mailto: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
