Your coding practices and documentation are not done well.

[Peter Ehrlich <pe...@gmail.com>]

I have just gone through a couple days of frustration and circles due to an
unexplained error message.  It turned out to be a problem with the
whitelist (which is broken), multiplied by indescriptive errors which only
show up on some API versions, and coupled with strong counter indications
as to what the issue really was caused by.

I'm sorry I can't cast this message in a more positive tone, but I'm more
frustrated than inspired at the moment.  I've linked to the thread at the
bottom of this message.

The bottom line is that I think the product you're all working so hard to
produce would benefit strongly from a concentrated focus on cross-team
communication/synchronization, documentation, and cross-platform
documentation.  (Or maybe I'm just a pampered Rails developer?)  I might
even suggest moving from the existing wiki system to the github one, so as
users will be encouraged to contribue through having existing accounts.

https://groups.google.com/forum/#!topic/phonegap/9NZ4J4l1I-s

Thanks,
--Peter

Re: Your coding practices and documentation are not done well.

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, Jan 13, 2012 at 10:26 PM, Patrick Mueller <pm...@gmail.com> wrote:
> For the first two items, my understanding is that only committers
> will be able to author that.

Right, but anyone is of course free to submit patches! For legal
reasons (everything officially released by the ASF should be traceable
back to a CLA or an equivalent license agreement) such contributions
need to be reviewed and accepted by a committer.

> The wiki is a little looser, but I don't completely understand the rules yet.

Basically anyone (who isn't banned for bad behavior like spamming) can
edit a wiki. The distinction here is that the wiki space is an open
collaboration space just like these mailing lists, not targeted or
released for redistribution by downstream users.

> We are still working out the process for how to accept commits from folks;
> you would need to an have an ICLA on file

An ICLA is only really needed for substantial contributions (like an
entire new component) and for project committers. It's good if a
contributor submits an ICLA, but not strictly required as the
licensing status of smaller contributions is already covered by
section 5 of ALv2 [1].

[1] http://www.apache.org/licenses/LICENSE-2.0

BR,

Jukka Zitting

Re: Your coding practices and documentation are not done well.

[Peter Ehrlich <pe...@gmail.com>]

>
>
>
> Peter, we hear you loud and clear. This was a pain point for the entire
> PhoneGap crew as well and we fought really hard, together with the CouchDB
> team and with the help of most/all of our Apache mentors to even get git
> approved as an acceptable form of source control! This project would not
> be at the level of popularity and exposure it currently enjoys without the
> help of github and its community, so transitioning to us from github to
> Apache infrastructure has been tough, but I know I am motivated to make it
> as easy and close to github as possible in terms of collaboration and
> exposure. If it's any solace, Apache git repositories that houses our code
> are mirrored over to github.com/apache, and you can fork those repos and
> send pull requests to that as you would with any other github repository.


Do they read this list? (heh)


> >Pick one repository (perhaps a new callback/cordova replacing
> >callback/phonegap) to be the master repo.  Link all other repos here for
> >general links, discussions, help, and wiki.  On this page include how to
> >contribue, the location of the google groups, your twitter handle, links
> >to
> >plugins and the API docs, and so on.
>
> This seems pretty reasonable too. Given we have multiple repositories (one
> for each platform), perhaps including a succinct version of this info in
> each repo's README would suffice?


Although it sounds benign, I'd hesitate to repeat information.  Not only is
it more work to maintain (which means it wont get done as often, as as
well, or that doing so will take away from good coding time) , but gives
users the job of verifying that it is the same on every repo, or being
caught when that's not the case.



> >I haven't tested yet, but try checking to be sure its never more than 2
> >clicks to go between what you're reading and a way to fix what you're
> >reading.
>
> I think some kind of "feedback" widget on the docs site used to exist (it
> would be visible on any page as a little tab on the side of your screen
> that slides out), but has been since removed. My understanding is that
> it's coming back soon.
>

Much better to have a way to edit directly, than a feedback 'black hole'.
 Among other reasons (again, less work for the team, and no doubt as to
value), it eases people in to ownership of sections of the project, and
gets them involved.

>
> I've started a new thread on the mailing list about how we can modify our
> documentation repository to address this issue (as well as merging in the
> various phonegap.com/start guides into the cordova docs repo). Hopefully
> we can get to a consensus there and start making the necessary
> modifications, and bring those online! If you have any suggestions, please
> chime in on that thread so we can get some more movement on that one.
>

Which mailing list?  I just took a look on the google group, but didn't see
(https://groups.google.com/forum/#!forum/phonegap)

Cheers,
--Peter

Re: Your coding practices and documentation are not done well.

[Peter Ehrlich <pe...@gmail.com>]

Sorry, just getting back to email after a few days

I will mention that anyone is welcome to quote any of the thing's I've
mentioned when talking to apache/whatever, if you think it could help the
case.

In the mean time I'll also put forward the idea of a more decentralized
community lead documentation system, which would be independent of any
Apache oversight.  For example, I've compiled wiki information here, and
will encourage other to follow suit:
http://stackoverflow.com/questions/8899608/what-is-the-state-of-whitelisting-in-phonegap-1-3-0

We could then make a wiki linking to the best SO questions & answers.  Its
only a shame that the phonegap tag page doesn't allow for a little more
cohesive functionality that way.

Cheers,
--Peter


On Mon, Jan 16, 2012 at 1:30 PM, Ross Gardler <rg...@opendirective.com>wrote:

> On 16 January 2012 18:18, Filip Maj <fi...@adobe.com> wrote:
> >
> >>Fil,
> >>
> >>Would you explain why fair governance and project neutrality depends upon
> >>Apache infrastructure?
> >
> > Fair governance and neutrality don't rely on any specific infrastructure
> > (be it Apache or GitHub), rather, the entity that owns the code in the
> > first place, and the processes that are followed by everyone to
> > collaborate on a project decide that. Apache is a not-for-profit
> > foundation that owns the code,
>
> Actually the ASF does not own the code, the individual contributors
> do. The ASF just has a licence to redistribute the code and the
> copyright in the collective work (as opposed to individual
> contributions).
>
> This doesn't change what you say, it just reinforces it further.
>
> Ross
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
>

Re: Your coding practices and documentation are not done well.

[Ross Gardler <rg...@opendirective.com>]

On 16 January 2012 18:18, Filip Maj <fi...@adobe.com> wrote:
>
>>Fil,
>>
>>Would you explain why fair governance and project neutrality depends upon
>>Apache infrastructure?
>
> Fair governance and neutrality don't rely on any specific infrastructure
> (be it Apache or GitHub), rather, the entity that owns the code in the
> first place, and the processes that are followed by everyone to
> collaborate on a project decide that. Apache is a not-for-profit
> foundation that owns the code,

Actually the ASF does not own the code, the individual contributors
do. The ASF just has a licence to redistribute the code and the
copyright in the collective work (as opposed to individual
contributions).

This doesn't change what you say, it just reinforces it further.

Ross


-- 
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com

Re: Your coding practices and documentation are not done well.

[Filip Maj <fi...@adobe.com>]

>Fil,
>
>Would you explain why fair governance and project neutrality depends upon
>Apache infrastructure?

Fair governance and neutrality don't rely on any specific infrastructure
(be it Apache or GitHub), rather, the entity that owns the code in the
first place, and the processes that are followed by everyone to
collaborate on a project decide that. Apache is a not-for-profit
foundation that owns the code, not a company that invests in the project
(like Adobe or IBM). Before the move to Apache, the PhoneGap project
relied on the "goodwill" of Nitobi and IBM in keeping the project open and
governed fairly. I remember where decisions on the future of the project
would be made by Nitobi folk, just because Nitobi as a company had to move
quickly or react to client needs, for example. It didn't affect the
project in a negative way, but I certainly wouldn't consider that
governance approach to be fair. Now in Apache there are a set of processes
and rules in place to guarantee that decisions affecting the project are
made in the open and are made on a consensus basis.

>I would have thought that popular, easily understood
>infrastructure like github provides the accessibility and transparency
>that
>fosters good governance. On the flip side, increasing learning curves and
>raising barriers would cause an increasing gap between governors and
>aspiring participants.
>
>Sorry if I'm reopening a can of worms. I'm ok if this is a topic you don't
>want to address again. I've been through the process of being bought by a
>big company.

Trust me, I would much prefer to work solely within GitHub's system, if
only for the ease of use :). Perhaps we can try to convince Apache +
GitHub to work more closely together to get the superior community
features of GitHub as a collaboration tool (not to mention the amount of
work they put into the product in general) approved into Apache's
processes. One can dream!

Re: Your coding practices and documentation are not done well.

[Paul Beusterien <pa...@gmail.com>]

Fil,

Would you explain why fair governance and project neutrality depends upon
Apache infrastructure? I would have thought that popular, easily understood
infrastructure like github provides the accessibility and transparency that
fosters good governance. On the flip side, increasing learning curves and
raising barriers would cause an increasing gap between governors and
aspiring participants.

Sorry if I'm reopening a can of worms. I'm ok if this is a topic you don't
want to address again. I've been through the process of being bought by a
big company.

thanks,
Paul

Re: Your coding practices and documentation are not done well.

[Filip Maj <fi...@adobe.com>]

On 12-01-13 3:13 PM, "Peter Ehrlich" <pe...@gmail.com> wrote:

>Hi everyone, and thanks for your responses
>
> > For now, opening a bug up on "improve documentation" with as much
> > excruciating detail as you are willing to give us, would be quite
>useful.
>
>Moving all issue tracking and documentation to Github would be an
>extremely
>good decision.  If you want to attract new developers, and crowdsource
>your
>documentation (and this is one of the only ways to get consistently good
>documentation), the Apache software will not do.
>
>Github is the most popular tool, and its growing.  I myself and those I
>know use it not only for finding code, but as a key part in
>the decision making process when considering new software.  The number of
>open/closed issues, as well as how they are handled and their age, tells
>more about the health repository than anything else I know.
>
>Github provides and even playing field.  As issues of all apps are
>presented equally, developers know how to interpret what they see.
>Equally
>good software on any other system wouldn't be as good, for the simple
>reason that the users --those people you want to see as contributors to
>Cordova-- are already familiar.
>
>Github has a company behind it, doing an unparalleled job on its issue
>tracker and wiki.
>
>Nobody's going to contribute so much as a bug report if they don't know
>their work is valued.  Compare the jira, where a bug report is fairly
>stark
>isolated, to a github bug report which is seen in the context of the other
>reports, and tied to the code and people that are involved in it, and well
>indexed by google.
>
>Github is a resumé item for contributors, just as stack overflow is.  When
>someone helps the project on github, their commits and comments continue
>give them credence in their profession, and github will continue to find
>new ways to do this.  Visibility of work is an incredibly motivating force
>(I feel that I can speak at least for beginning coders.)

Peter, we hear you loud and clear. This was a pain point for the entire
PhoneGap crew as well and we fought really hard, together with the CouchDB
team and with the help of most/all of our Apache mentors to even get git
approved as an acceptable form of source control! This project would not
be at the level of popularity and exposure it currently enjoys without the
help of github and its community, so transitioning to us from github to
Apache infrastructure has been tough, but I know I am motivated to make it
as easy and close to github as possible in terms of collaboration and
exposure. If it's any solace, Apache git repositories that houses our code
are mirrored over to github.com/apache, and you can fork those repos and
send pull requests to that as you would with any other github repository.

>If Apache demands that the usage of their proprietary software be put over
>an intrinsically better system, be it github or anything else, then they
>are foolish.

Apache did, but git is now acceptable as of maybe a month ago. The
requirements to keep the code and other things like issue tracker and wiki
on Apache infrastructure, from my understanding, is more about legal
issues and less about control or anything else. Getting into Apache
guarantees fair governance of the project as well as project neutrality
which, in my mind, is more important than where the issue tracker is
(which can be solved with good documentation). I understand that github
and the community it harbours are extremely important assets for any open
source project, but in the long run the move to Apache will benefit us and
you. And trust me, we're not disappearing from GitHub!

>Here's how I would fix documentation:

These are great - thank you for these!

>
>Start with a Steve Jobsian passion for deleting things.  Mark the entire
>wiki (http://wiki.phonegap.com/w/page/16494772/FrontPage) for deletion,
>and
>work on moving the good stuff to new locations (see below).  This is not
>software you want to be working with-- even the official rails wiki (
>http://wiki.rubyonrails.org/) is singularly outta date and useless.

Totally. As soon as the new Apache-blessed wiki is online we are going to
do just that.

>Cordova is a complex and multi-layered project.  I think I see natural
>divides in to device-specific implementations, a shared javascript api,
>and
>thirdly strong design patterns shared across devices.  This third category
>includes plugins and things such as whitelist implementation; I imagine it
>will grow more as Cordova matures.
>
>Move device-specific documentation to their github readme.md files, and if
>necessary, specific wiki pages.  This is not a difficult job, especially
>if
>you already have the repo forked.  Make sure that every device repo has
>its
>wiki enabled, this is important, as it's not a default.

I would suggest that, because we'll be using an Apache wiki, we can
instead link to it from each project's README.

>Pick one repository (perhaps a new callback/cordova replacing
>callback/phonegap) to be the master repo.  Link all other repos here for
>general links, discussions, help, and wiki.  On this page include how to
>contribue, the location of the google groups, your twitter handle, links
>to
>plugins and the API docs, and so on.

This seems pretty reasonable too. Given we have multiple repositories (one
for each platform), perhaps including a succinct version of this info in
each repo's README would suffice?

>I don't know enough about the shadowing to say how easy all this is to do,
>but the effect would be powerful.  Licenses are sounding like a non-issue;
>but if that's not the case, get in touch with github.  Surely its a
>problem
>they've run in to before, and either would have idea for a solution, or
>maybe could be talked in to rolling some custom features for you and
>anyone
>else needing licensing.

This is a great idea; however, not sure how the Apache "old guard" would
feel about this. I will volunteer to explore this option within Apache if
it's an option.

>I haven't tested yet, but try checking to be sure its never more than 2
>clicks to go between what you're reading and a way to fix what you're
>reading.

I think some kind of "feedback" widget on the docs site used to exist (it
would be visible on any page as a little tab on the side of your screen
that slides out), but has been since removed. My understanding is that
it's coming back soon.

>Oh, and looks like bug report about the whitelist got taken up, sweet!  As
>it stands there's no apparent place to add documentation about the
>feature,
>but I believe the google group post will show up well on google.

I've started a new thread on the mailing list about how we can modify our
documentation repository to address this issue (as well as merging in the
various phonegap.com/start guides into the cordova docs repo). Hopefully
we can get to a consensus there and start making the necessary
modifications, and bring those online! If you have any suggestions, please
chime in on that thread so we can get some more movement on that one.

>And I didn't say this earlier, but thanks for all the hard work.  I'm
>excited to see what's coming up in 1.4!
>
>Finally, I've been toying somewhat with a jquery wrapper library, with a
>hope of resulting in a simpler intuitive API.  It's only involving photo
>capturing for now, but hopefully I can make it public and useful to others
>soon.

I'm always keen on seeing what people come up with :)

Re: Your coding practices and documentation are not done well.

[Peter Ehrlich <pe...@gmail.com>]

Hi everyone, and thanks for your responses

 > For now, opening a bug up on "improve documentation" with as much
 > excruciating detail as you are willing to give us, would be quite useful.

Moving all issue tracking and documentation to Github would be an extremely
good decision.  If you want to attract new developers, and crowdsource your
documentation (and this is one of the only ways to get consistently good
documentation), the Apache software will not do.

Github is the most popular tool, and its growing.  I myself and those I
know use it not only for finding code, but as a key part in
the decision making process when considering new software.  The number of
open/closed issues, as well as how they are handled and their age, tells
more about the health repository than anything else I know.

Github provides and even playing field.  As issues of all apps are
presented equally, developers know how to interpret what they see.  Equally
good software on any other system wouldn't be as good, for the simple
reason that the users --those people you want to see as contributors to
Cordova-- are already familiar.

Github has a company behind it, doing an unparalleled job on its issue
tracker and wiki.

Nobody's going to contribute so much as a bug report if they don't know
their work is valued.  Compare the jira, where a bug report is fairly stark
isolated, to a github bug report which is seen in the context of the other
reports, and tied to the code and people that are involved in it, and well
indexed by google.

Github is a resumé item for contributors, just as stack overflow is.  When
someone helps the project on github, their commits and comments continue
give them credence in their profession, and github will continue to find
new ways to do this.  Visibility of work is an incredibly motivating force
(I feel that I can speak at least for beginning coders.)


If Apache demands that the usage of their proprietary software be put over
an intrinsically better system, be it github or anything else, then they
are foolish.


Here's how I would fix documentation:

Start with a Steve Jobsian passion for deleting things.  Mark the entire
wiki (http://wiki.phonegap.com/w/page/16494772/FrontPage) for deletion, and
work on moving the good stuff to new locations (see below).  This is not
software you want to be working with-- even the official rails wiki (
http://wiki.rubyonrails.org/) is singularly outta date and useless.

Cordova is a complex and multi-layered project.  I think I see natural
divides in to device-specific implementations, a shared javascript api, and
thirdly strong design patterns shared across devices.  This third category
includes plugins and things such as whitelist implementation; I imagine it
will grow more as Cordova matures.

Move device-specific documentation to their github readme.md files, and if
necessary, specific wiki pages.  This is not a difficult job, especially if
you already have the repo forked.  Make sure that every device repo has its
wiki enabled, this is important, as it's not a default.

Pick one repository (perhaps a new callback/cordova replacing
callback/phonegap) to be the master repo.  Link all other repos here for
general links, discussions, help, and wiki.  On this page include how to
contribue, the location of the google groups, your twitter handle, links to
plugins and the API docs, and so on.

I don't know enough about the shadowing to say how easy all this is to do,
but the effect would be powerful.  Licenses are sounding like a non-issue;
but if that's not the case, get in touch with github.  Surely its a problem
they've run in to before, and either would have idea for a solution, or
maybe could be talked in to rolling some custom features for you and anyone
else needing licensing.


I haven't tested yet, but try checking to be sure its never more than 2
clicks to go between what you're reading and a way to fix what you're
reading.

Oh, and looks like bug report about the whitelist got taken up, sweet!  As
it stands there's no apparent place to add documentation about the feature,
but I believe the google group post will show up well on google.

And I didn't say this earlier, but thanks for all the hard work.  I'm
excited to see what's coming up in 1.4!

Finally, I've been toying somewhat with a jquery wrapper library, with a
hope of resulting in a simpler intuitive API.  It's only involving photo
capturing for now, but hopefully I can make it public and useful to others
soon.

Cheers,
--Peter





On Fri, Jan 13, 2012 at 4:26 PM, Patrick Mueller <pm...@gmail.com> wrote:

> On Fri, Jan 13, 2012 at 15:03, Peter Ehrlich <peter.i.ehrlich@gmail.com
> >wrote:
>
> > The bottom line is that I think the product you're all working so hard to
> > produce would benefit strongly from a concentrated focus on cross-team
> > communication/synchronization, documentation, and cross-platform
> > documentation.  (Or maybe I'm just a pampered Rails developer?)  I might
> > even suggest moving from the existing wiki system to the github one, so
> as
> > users will be encouraged to contribue through having existing accounts.
> > --Peter
>
>
> I think providing more documentation, especially regarding
> platform-specific issues (whitelists, etc), is something we should be
> doing.  Could you open a bug?
>
>    https://issues.apache.org/jira/browse/CB
>
> In terms of engaging more folks to help with the documentation, there are
> three different ways I see us providing doc at Apache:
>
> - the main site: http://incubator.apache.org/callback/ (will be renamed
> cordova some day)
> - documentation shipped with releases
> - the wiki: (does not yet exist AFAIK)
>
> For the first two items, my understanding is that only committers will be
> able to author that.  The wiki is a little looser, but I don't completely
> understand the rules yet.
>
> We currently have shadows of the git repos at apache, at GitHub.  Here's
> the doc project, which contains the documentation shipped with the
> releases:
>
>    https://github.com/apache/incubator-cordova-docs
>
> We are still working out the process for how to accept commits from folks;
> you would need to an have an ICLA on file -
> http://www.apache.org/licenses/icla.txt , but we're hoping you can fork
> the
> GitHub repo, and somehow issue a pull request to make a contribution.
>
> For now, opening a bug up on "improve documentation" with as much
> excruciating detail as you are willing to give us, would be quite useful.
>
> --
> Patrick Mueller
> http://muellerware.org
>

Re: Your coding practices and documentation are not done well.

[Patrick Mueller <pm...@gmail.com>]

On Fri, Jan 13, 2012 at 15:03, Peter Ehrlich <pe...@gmail.com>wrote:

> The bottom line is that I think the product you're all working so hard to
> produce would benefit strongly from a concentrated focus on cross-team
> communication/synchronization, documentation, and cross-platform
> documentation.  (Or maybe I'm just a pampered Rails developer?)  I might
> even suggest moving from the existing wiki system to the github one, so as
> users will be encouraged to contribue through having existing accounts.
> --Peter


I think providing more documentation, especially regarding
platform-specific issues (whitelists, etc), is something we should be
doing.  Could you open a bug?

    https://issues.apache.org/jira/browse/CB

In terms of engaging more folks to help with the documentation, there are
three different ways I see us providing doc at Apache:

- the main site: http://incubator.apache.org/callback/ (will be renamed
cordova some day)
- documentation shipped with releases
- the wiki: (does not yet exist AFAIK)

For the first two items, my understanding is that only committers will be
able to author that.  The wiki is a little looser, but I don't completely
understand the rules yet.

We currently have shadows of the git repos at apache, at GitHub.  Here's
the doc project, which contains the documentation shipped with the releases:

    https://github.com/apache/incubator-cordova-docs

We are still working out the process for how to accept commits from folks;
you would need to an have an ICLA on file -
http://www.apache.org/licenses/icla.txt , but we're hoping you can fork the
GitHub repo, and somehow issue a pull request to make a contribution.

For now, opening a bug up on "improve documentation" with as much
excruciating detail as you are willing to give us, would be quite useful.

-- 
Patrick Mueller
http://muellerware.org

Re: Your coding practices and documentation are not done well.

[Brian LeRoux <b...@brian.io>]

Geez, really sorry to hear that experience Peter. This definitely is
not the experience we want developers to have and I appreciate that
you took the time to share your frustration with us. I myself would
probably have given up.

To echo Patrick and Fil: please do not hesitate to give us this
feedback.in the form of bugs, and if you are willing patches. Another
good avenue for help is either our irc #phonegap or many of us camp
out on the search term 'phonegap' on twitter. This list is also a good
place to escalate.

The whitelist feature does need love. My feeling is that it should be
* by default but thats probably better left for a different thread of
discussion. Hopefully our new wiki will be up in short order so we can
better document it. =/

One other small point, the phonegap.js file is currently being
refactored into a single file across platforms in a much nicer, more
modern, cleaner and better architected style. This doesn't directly
solve the whitelist issue but will make debugging of this nature much
less of a black art!


On Fri, Jan 13, 2012 at 1:38 PM, Filip Maj <fi...@adobe.com> wrote:
> Thanks for your e-mail Peter. We are still transitioning into Apache from
> a previous "run-n-gun" type of organizational structure so there will be
> some amount of time where we're all a little out of sync. Additionally we
> don't have many full-time developers working on the project at the moment
> (by my count somewhere around 6), to cover five different mobile platform
> implementations + cross-platform documentation ... We would love
> contributions from you if you feel you can make it better!
>
> On 12-01-13 12:03 PM, "Peter Ehrlich" <pe...@gmail.com> wrote:
>
>>I have just gone through a couple days of frustration and circles due to
>>an
>>unexplained error message.  It turned out to be a problem with the
>>whitelist (which is broken), multiplied by indescriptive errors which only
>>show up on some API versions, and coupled with strong counter indications
>>as to what the issue really was caused by.
>>
>>I'm sorry I can't cast this message in a more positive tone, but I'm more
>>frustrated than inspired at the moment.  I've linked to the thread at the
>>bottom of this message.
>>
>>The bottom line is that I think the product you're all working so hard to
>>produce would benefit strongly from a concentrated focus on cross-team
>>communication/synchronization, documentation, and cross-platform
>>documentation.  (Or maybe I'm just a pampered Rails developer?)  I might
>>even suggest moving from the existing wiki system to the github one, so as
>>users will be encouraged to contribue through having existing accounts.
>
> Unfortunately this is not an option under Apache. My understanding is that
> the wiki and source code servers must be on Apache infrastructure, so
> moving forward GitHub will be less of a de-facto collaboration point. We
> are still working on bringing the wiki up online, so once we have all of
> the infrastructure figured out we will be sure to update the community.
>

Re: Your coding practices and documentation are not done well.

[Filip Maj <fi...@adobe.com>]

Thanks for your e-mail Peter. We are still transitioning into Apache from
a previous "run-n-gun" type of organizational structure so there will be
some amount of time where we're all a little out of sync. Additionally we
don't have many full-time developers working on the project at the moment
(by my count somewhere around 6), to cover five different mobile platform
implementations + cross-platform documentation ... We would love
contributions from you if you feel you can make it better!

On 12-01-13 12:03 PM, "Peter Ehrlich" <pe...@gmail.com> wrote:

>I have just gone through a couple days of frustration and circles due to
>an
>unexplained error message.  It turned out to be a problem with the
>whitelist (which is broken), multiplied by indescriptive errors which only
>show up on some API versions, and coupled with strong counter indications
>as to what the issue really was caused by.
>
>I'm sorry I can't cast this message in a more positive tone, but I'm more
>frustrated than inspired at the moment.  I've linked to the thread at the
>bottom of this message.
>
>The bottom line is that I think the product you're all working so hard to
>produce would benefit strongly from a concentrated focus on cross-team
>communication/synchronization, documentation, and cross-platform
>documentation.  (Or maybe I'm just a pampered Rails developer?)  I might
>even suggest moving from the existing wiki system to the github one, so as
>users will be encouraged to contribue through having existing accounts.

Unfortunately this is not an option under Apache. My understanding is that
the wiki and source code servers must be on Apache infrastructure, so
moving forward GitHub will be less of a de-facto collaboration point. We
are still working on bringing the wiki up online, so once we have all of
the infrastructure figured out we will be sure to update the community.