Collaborate with us using ARO Open Source

[#1]

ARO has been making mobile news!  Check out this CNET article detailing the battery saving benefits that the tool provides:

http://news.cnet.com/8301-1035_3-57445772-94/how-an-at-t-tool-can-make-your-app-more-efficient/?tag=....  

Now that ARO source code is available for download at github.com, the AT&T Developer Program would love to hear feedback and ideas on what would make it a more useful development tool.  Post your comments here!

[#2]

What is the Developer Program's preferred approach to making contributions to the ARO tool? Given that AT&T Developer Program team appear to be working on updates to the tool internally (as evidenced by a beta Collector APK posted to github last week), it would be good to understand how best to contribute changes so that they are easy to integrate.

For example, if a bug is found along with a fix should this be raised as an Issue on the github site, and the fix created in a new branch off Master in forked repository on Github? When the fix is tested and ready for contribution, should the developer then submit a Pull request on the main ARO github site? Or should the bug fix branch be merged back into master on the forked repository, then a Pull request raised?

Do updated ARO binaries need to be committed in addition to the source change (this makes merging/pulling less trivial) or is the long-term plan to remove the ARO binaries from the repository?

For enhancements (not bug fixes) to the ARO tool is the above approach applicable? For example, create a feature branch in a forked repository and then raise a pull request? Or is some other process preferable? Is a GitHub Issue needed to support/document a feature contribution?

[#3]

Thanks for your query. Our apologies that the response is so late, we were experiencing some technical issues and hence the delay.  As you noticed, we are actively enhancing ARO with new features and would love to have your participation.  We are actively collaborating with quite a few partners through our AT&T channels and would like to extend the same to our Github partners.  

You’ve raised some good questions and we plan on placing a document in Wiki that explains this process.  Basically, we are an AGILE shop, so we will evaluate each submission monthly. We would prefer to communicate more openly (phone calls, emails), but can also track the enhancements/bugs via the “Issues” feature in Github.  If you have a feature request or bug fixes, please raise an issue tagged as Bug or Enhancement along with a pull request.  For ease of use, please make each enhancement a separate fork with comments and pull requests.  After we have evaluated each pull request, we will determine whether it will be integrated into the main branch. Regarding the ARO binaries, purpose of binary is for wider audience for running ARO tool (Collection/Analysis) and for any code contribution we don't want binary to be submitted. The plan would be create the binary once code is merged with main branch. Regarding the ARO binaries, we do not want these committed.  The purpose of binary is for wider audience for running ARO tool (Collection/Analysis).  The plan would be create the binary once code is merged with main base.

If you have features that you would like to pursue, you may want to contact us (developer.program@att.com) beforehand to ensure that we are not already working on the feature.  We would love to have a forum for people to actively contribute and would love to hear your ideas.