Offering to maintain Charts

Thank you Nickolay !

Thank you Nate for accepting my offer, and your recommendations/guidelines in#3. Just assume I'll try to have charts continue in that direction also. For other libs to eventually be supported in the future (e.g. because of licensing needs?), it appears that the comment in #2364427-5: Renderer for Charts and Graphs APIs might be a valid alternative.

Thank you Brad also for your #2368793-20: Chart 2.0 suggestion, which was part of the reason for my offer.

I hope that you'll both continue to be available for some type of assistance in case I'm running into issues while working on topics related to migration from chart to charts ...

With that, and with Nickolay as a reprezentative "consumer" of chart and charts, I look forward to the day that those +25K chart sites are no longer facing the current April 2015 deadline.

PS: whenever I use "chart(s)" from now on, I'll use it as a shortcut of something somewhere in chart, charts or both.

I'm reopening this issue, and adapting the title of it. I trust the new title is clear enough, and would like to know Nate's (Quicksketch) opinion about it.

Please checkout what I wrote in #2371075-22: Chart 7.x-2.x Release a few days ago (it's in the chart issue queue, but part of that comment relates to chartS). And apart from that, I'd like to briefly inform all people following this issue about how "I" see the future of both chart and charts:

1. Quickwin (as a shorttime solution for the approaching april 2015 deadline): Upgrade chart module to replace the current GIC library by their equivalent GC library. And this by starting from about 2 open issues that have a prototype of it attached already. Haven't verified yet if all (old) GIC options can be mapped to a corresponding GC option. Those options that cannot mapped will be ignored (I don't see any other alternative for that).
2. Finalise (= release) the ongoing RC1 release of charts (so that charts is stable and ready for the next phase of chart (see next step).
3. Make charts a module dependency for chart, so that within chart we can gradually transform anything related to the GIC library into a call to charts, using the GC library, and this for any chart feature for which there is a matching chart feature.
4. For chart features for which there is no matching charts feature (eg some type of map (like QR code?), or some special charting option), we need to try to come up with an alternative within chart, by trying to replace those features with another charting library to be supported within chart. Most probably it'll become one of the (open source) libraries like d3.js (JS), SVG Graph (PHP) or pChart(PHP). Because of my forena background I do have some experience with 2 of these 3 libs, while for pChart I have the 'Visitors' module as a working sample. I'm not decided yet which of those 3 libs to go for at first, but in the long run I want to support all 3 of them in ... chart. Potentially with other libs to be added afterwards. Variation of all this might be that we enhance charts to add support for 1 or more of these 3 libs (don't know which module would be the best fit, but more and more I'm thinking of adding them to charts, not chart). So for whatever lib we decide to put support for it in charts, the chart module will use charts to actually use that library.
5. Ideally (in my opinion), in the end chart will depend on charts for any of it's supported (via charts) libraries. That would make chart a module that itself does not do any rendering anymore, but instead delegates it to the charts module. By doing so, I would want to have chart evolve in 2 new directions: (a) do charting about DATA stored in 'other' RDBMs, like Oracle, MS Sql, etc and (b) add some type of GUI for building the $chart array, so that it can be used also by people with site building skills (instead of PHP skills right now). For (a) I'm thinking of a (weak) module dependency to module forena (weak = no forena available, then not supported). For (b) I'm thinking of something similar to forena's "WYSIWYG reporting editor", but that'll be something only added to chart, and probably not to charts (anybody from charts who would want this, must accept to use chart for it, which via it's module dependency to charts will ensure that charts continues to be used under the cover).
6. Upgrade both chart and charts, to provide support for B.O.T.H. D8 and ... right, Backdrop (we owe that to Nate, for the great work he did for charts ... period And that shouldn't be too hard to do ... also)!

Note: with the approach above the impact for existing chart users is mimimal. They can continue to use chart (provided they perform a typical module upgrade of chart), or they still have the choice to "migrate" from chart to charts of that's what they prefer. And THAT is what I believe is extremely important. Somebody like Plazik can now decide in his module what he prefers most. For me what counts here (in the context of my chart 2.0 goal) is that such chart user either remains a chart user, or otherwise moves on to its brother (or sister?) called charts. With a total nr of reported installs around 26K + 9K = 35K that's about the 10 fold of all other native charting modules together. Hopefully some day we can convince those other modules to also join forces with chart(s).

After digesting what is above, and hoping that you can agree to what I'm up to, I would like Nate to consider this: how about we swap maintainer-status?

Reason why I ask: it might help to convince my current sponsor to continue sponsoring me to reach my goal as initially described in this issue.

PS 1: If for some reason you cannot accept my request, or not yet, no problem, don't worry, OK ?
PS 2 (to Nickolay aka Plazik): wanna tweet again like in #1 ?