Agree this sort of thing belongs in the JS --- sub component makes sense since its a new proj that stands alone anyhow. I think, and mentors pls correct me here, that the first step is a general [DISCUSS] thread, followed or accompanied by a [POLL] to help determine options, followed by a [VOTE] if rough consensus isn't good enough.
>From there, add an issue to JIRA and get hacking. Once its done, well, we have a process there currently that is informal w/ pull requests on Github but I suspect we may want to formalize it a bit more w/ an email identifying the patch/pull req on github for others to verify before the final merge. On Thu, Dec 1, 2011 at 12:28 PM, Filip Maj <[email protected]> wrote: > What do we do when we have platform-agnostic changes to introduce? Or want to > suggest a change for the API in general? For example, adding a new option to > some callback API, like allowing arbitrary headers to be set on a > FileTransfer object. > > Does it make sense to add a new component to JIRA, like a JS component? There > would be a tight mapping from JS/API tickets to the callback-js project. > Another related question is, where is the starting point for development for > these kinds of issues? My intuition is the callback-js project and the docs… > > Obviously the first step is to vet the changes out on the mailing list so > everyone can chime in. But say we agree on a change – what's the next step > after that?
