I know some of the plugins (all of them?) call out at the top of the docs that they are based on standards. I think we should be more dilligent in referencing those specs when discussing/weighing changes to the APIs.
It would be a lot easier to maintain a stance such as "this does not follow the spec, thus we cannot accept it" if we walked the walk and didn't just talk the talk. By that I mean that we should put effort in: a) modernizing the plugins that are still valuable, b) making the hard decisions to remove outdated plugins, and c) blogging/documenting transition paths for consumers of plugins we decide to get rid of The sooner we do this the less of a burden on the project. On Tue, Apr 25, 2017 at 2:56 PM, julio cesar sanchez <[email protected]> wrote: > Whenever I see a PR for a new feature I tell the author to send a mail to > discuss it, most of them don't do it. > > > 2017-04-25 22:22 GMT+02:00 Simon MacDonald <[email protected]>: > >> Hey Shazon, >> >> I agree with this goal. Our plugins were based upon W3C standards as >> they existed when the plugins were created. The standards have moved >> on and we haven't had as much time as we would like to stay in sync. A >> number of core plugins have been superseded by API's already available >> in browsers (I'm looking at you, cordova-plugin-device-motion). >> >> Changes to any of the core plugins should align themselves with W3C >> specs so we can increase code reuse across platforms and decrease our >> support and maintenance costs. >> >> >> Simon Mac Donald >> http://simonmacdonald.com >> >> >> On Tue, Apr 25, 2017 at 4:07 PM, Shazron <[email protected]> wrote: >> > Resources are limited and we can barely keep up with all the core plugin >> > work that needs to be done, so we have to have a process with dealing >> with >> > desired features that community members send out as PRs. >> > >> > Firstly I want to acknowledge that external contributions are valued >> highly >> > by the team, but they need to fulfill Cordova's goals and not be a >> > maintenance burden on the project. >> > >> > GOAL: >> > Core plugins should conform to standards whenever possible, and we should >> > not add new features nor expand existing features without a consensus on >> > dev@ >> > >> > ROADMAP: >> > I will be putting out another thread where I will propose a concrete >> > roadmap for the existing core plugins -- listing those that will make the >> > maintenance cut, and/or listing those that are scheduled for sunset. So >> put >> > your two cents there. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
