{"action":"created","issue":{"url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/658","labels_url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/658/labels{/name}","comments_url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/658/comments","events_url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/658/events","html_url":"https://github.com/dcjones/Gadfly.jl/issues/658","id":101183983,"number":658,"title":"RFC: unify plotting packages under a common organization","user":{"login":"waldyrious","id":478237,"avatar_url":"https://avatars.githubusercontent.com/u/478237?v=3","gravatar_id":"","url":"https://api.github.com/users/waldyrious","html_url":"https://github.com/waldyrious","followers_url":"https://api.github.com/users/waldyrious/followers","following_url":"https://api.github.com/users/waldyrious/following{/other_user}","gists_url":"https://api.github.com/users/waldyrious/gists{/gist_id}","starred_url":"https://api.github.com/users/waldyrious/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/waldyrious/subscriptions","organizations_url":"https://api.github.com/users/waldyrious/orgs","repos_url":"https://api.github.com/users/waldyrious/repos","events_url":"https://api.github.com/users/waldyrious/events{/privacy}","received_events_url":"https://api.github.com/users/waldyrious/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-08-15T15:11:21Z","updated_at":"2015-08-17T03:09:05Z","closed_at":null,"body":"I originally suggested this in sunetos/TextPlots.jl#15, where it was briefly discussed, but since the subject was kind of off-topic there, and the PR was (rightfully) closed, I thought it would be better to re-launch the discussion elsewhere. I'm posting it here since it's by far the most popular (by github stars at least) plotting package for Julia.\r\n\r\nThe suggestion is for the owners of Julia's plotting packages to join under an organization, which would have several benefits, which I point out below. For reference, the current plotting packages are:\r\n\r\nText-based plotting:\r\n\r\n- @sunetos' [TextPlots.jl](https://github.com/sunetos/TextPlots.jl)\r\n- @johnmyleswhite's [ASCIIPlots.jl](https://github.com/johnmyleswhite/ASCIIPlots.jl)\r\n- @mbauman's [Sparklines.jl](https://github.com/mbauman/Sparklines.jl)\r\n- @Evizero's [UnicodePlots.jl](https://github.com/Evizero/UnicodePlots.jl)\r\n- @ninjin's [Hinton.jl](https://github.com/ninjin/Hinton.jl) (also outputs vector graphics)\r\n\r\nGraphical plotting (possibly incomplete list):\r\n\r\n- @dcjones' [Gadfly.jl](https://github.com/dcjones/Gadfly.jl)\r\n- @stevengj's [PyPlot.jl](https://github.com/stevengj/PyPlot.jl)\r\n- @nolta's [Winston.jl](https://github.com/nolta/Winston.jl)\r\n- @mbaz's [Gaston.jl](https://github.com/mbaz/Gaston.jl)\r\n- @Mononofu's [julia-plot](https://github.com/Mononofu/julia-plot)\r\n- @SimonDanisch's [GLPlot.jl](https://github.com/SimonDanisch/GLPlot.jl)\r\n- @tbreloff's [Qwt.jl](https://github.com/tbreloff/Qwt.jl)\r\n- @bokeh's [Bokeh.jl](https://github.com/bokeh/Bokeh.jl)\r\n- @plotly's [Plotly.jl](https://github.com/plotly/Plotly.jl)\r\n- @jverzani's [GoogleCharts.jl](https://github.com/jverzani/GoogleCharts.jl)\r\n- @johnmyleswhite's [Vega.jl](https://github.com/johnmyleswhite/Vega.jl)\r\n\r\nAdditionally, there are some graph-specific packages which I suppose would fit into a plotting organization, but since [JuliaGraphs](https://github.com/JuliaGraphs) exists, they should probably unite there instead:\r\n\r\n- @Keno's [GraphViz.jl](https://github.com/Keno/GraphViz.jl)\r\n- @sisl's [TikzGraphs.jl](https://github.com/sisl/TikzGraphs.jl)\r\n- @IainNZ's [GraphLayout.jl](https://github.com/IainNZ/GraphLayout.jl)\r\n\r\nThe advantages for an organization are:\r\n\r\n1. It would make it less harmful if the *de facto* maintainer of a package became absent or semi-absent for a long period of time, since other members of the organization could at least merge simple fixes (compatibility changes, readme edits, documentation, etc.), and new people who start contributing a lot to a given package could be added to the organization to help maintain the package.\r\n2. It would provide a curated list of plotting packages, making it much easier to find the various options available (it took me quite a while to collect the list above, sifting through long julia-users threads and other online resources). For example, http://julialang.org/downloads/plotting.html only mentions Gadfly and PyPlot.\r\n3. As @tbreloff mentioned in the previous discussion, such an organization would be the ideal place to maintain a \"document/tutorial that describes the pros/cons of the packages, compares usage for common workflows, dependencies, and features\", further adding that he'd be interested in contributing (as would I).\r\n4. More of a long shot, but nothing is lost for trying: maybe that organization could facilitate convergence efforts to unify plotting options in Julia. At the very least, there would be a central place for discussions to happen.\r\n\r\nAs I see it, we have nothing to lose, and everything to gain: at worst we will have a situation just like right now, but with the benefit of having all plotting platforms in the same place. That's already a net positive, without the need for any further action. And at best, we have the chance to really improve the state of plotting in Julia, which arguably is a quite common need, therefore hopefully commanding enough interest and energy to make things go forward, concerning items 1, 3 and even 4 from the list above.\r\n\r\nLooking forward to hear from the authors of the packages listed above (and any others interested in this topic)."},"comment":{"url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/comments/131665102","html_url":"https://github.com/dcjones/Gadfly.jl/issues/658#issuecomment-131665102","issue_url":"https://api.github.com/repos/dcjones/Gadfly.jl/issues/658","id":131665102,"user":{"login":"waldyrious","id":478237,"avatar_url":"https://avatars.githubusercontent.com/u/478237?v=3","gravatar_id":"","url":"https://api.github.com/users/waldyrious","html_url":"https://github.com/waldyrious","followers_url":"https://api.github.com/users/waldyrious/followers","following_url":"https://api.github.com/users/waldyrious/following{/other_user}","gists_url":"https://api.github.com/users/waldyrious/gists{/gist_id}","starred_url":"https://api.github.com/users/waldyrious/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/waldyrious/subscriptions","organizations_url":"https://api.github.com/users/waldyrious/orgs","repos_url":"https://api.github.com/users/waldyrious/repos","events_url":"https://api.github.com/users/waldyrious/events{/privacy}","received_events_url":"https://api.github.com/users/waldyrious/received_events","type":"User","site_admin":false},"created_at":"2015-08-17T03:09:05Z","updated_at":"2015-08-17T03:09:05Z","body":"To address @johnmyleswhite's (and @IainNZ's) points, the intention was never to *generate* new energy/labor (or in any way ask the package managers to do more than they are currently doing!), but merely to set up the structure that would allow e.g. convergence efforts once people are available to do so. In the meantime, it would provide a central location to find all plotting packages (definitely not \"nothing\" to gain), it would be the ideal host for the document @tbreloff talks about (which I reiterate my willingness to help work on), and especially, it would allow *existing* \"labor supply\" (unmerged PRs, especially simple ones) to be better channeled.\r\n\r\nIn fact, let me expand on this latter point for a bit: It may not be evident for you as someone who has commit access to many of the ecosystem's main packages, and commands the prompt attention of community members, but from an outsider's point of view, having very simple patches [linger for weeks](https://github.com/dcjones/Gadfly.jl/pull/480) or even [not merged at all](https://github.com/sunetos/TextPlots.jl/pull/9) definitely doesn't encourage more substantial contributions. Add to this the fact that by the time a PR is merged the person may not have as much time available as they did when they sent the first PR, or may have unloaded the mental model of the package (which takes significant effort to acquire when dealing with someone else's code), or the model became unsynchronized with recent upstream changes to Julia, etc., and it may become clearer why I feel this aspect is so important to address. I'm positive that an organization could provide a more responsive ramp-up for new contributors, and I say this from experience: my (modest) PRs to julia proper have had much prompter responses from various people, while contributions to single-owner, less popular packages typically take longer to have responses, for obvious (and understandable) reasons. @timholy's observation to the contrary probably only applies to a limited subset of packages whose owners are both very active in julia development and take care to address PRs/issues early, which isn't the general case (but please correct me if I'm wrong).\r\n\r\nFor all the above, I ask you to reconsider the potential benefits of an organization. It may not mean much to powerhouse contributors, but it most definitely doesn't have a null effect."}}