APM Dev Community Launch ACTIONS

Document created by Chris Kline Employee on Nov 4, 2014Last modified by Chris Kline Employee on Nov 4, 2014
Version 2Show Document
  • View in full screen mode

The following are volunteered to help launch this community:

Mchael Walker

Andreas Reiss

Omar Ocampo

Florian Cheval

Guenter Grossberger

Haruhiko Davis

Haroon Ahmed



  • Web Page Home.  This is a landing page for the overall CAAPM GitHub presence.  It is itself a repo (ca-apm.github.io) which we can post anything we want to).
  • Org Home.  This is a list of all public repo’s that we maintain.
  • Repo Home.  This is the MongoDB repo itself.  This is the template repo at this time.
  • Github Repo Wiki Page.  This is meant to be the high-level description of the project (from a user and not developer POV).  It doesn’t have installation instructions but points to what the extension does, provides screenshots, and links to the download (releases) page.  This is the landing page we’ll point to from somewhere on ca.com (other teams are working on a catalog/marketplace where all assets--whether hosted on github or elsewhere—will be indexed and linked.  That’s our next step once we land all the github stuff.
  • Project Docs.  Each project will start at README.md, which will really just be a pointer page to a few other markdown pages, explaining what’s where.  It is designed to be cloneable and not have project-specific content.
    • RELEASENOTES.md.  This is the primary customized file with description, installation & configuration, and developer details (such as how to build, run tests, etc.)
    • CHANGELOG.md.  Will keep track of merged changes.  Normal github styling.
    • CONTRIBUTING.md.  This is a boilerplate doc (with APM wording) that explains steps one would go through in order to contribute to the project.
    • LICENSE.md.  Will be a literal copy-paste of either EPL or AL licenses; all other license references point to this file so we can swap licenses at will when we start a new repo.



  1. Need to post various blogs/docs to the APM Dev community which explain what’s where, etc. 
    1. Overall explanation
    2. How to get started as a contributor
      1. Difference between EPL and APL, when to use each
    3. How to download and setup EPA 9.7.1 (via CVP until fix pack comes out in Jan)
    4. Code Examples for EPA
    5. Blogs on how to do PBD.  Make them funny.  Don’t even need to be CAAPM specific (like AD)
    6. YouTube videos on how to do things.  How to do RESTful interface, PBD.  Keep them to 3-4min.
  2. The following pages are referenced but do not yet exist:
    1. become a contributor (CLA) https://communities.ca.com/become-a-contributor
    2. how to do testing https://communities.ca.com/testing
    3. (referenced from CONTRIBUTING.md) office hours:  We hold regular "office hours" on CA Communities that you can join to review contributions together, ask questions about contributing, or just hang out with CA APM Software employees. The regularly scheduled CA APM hangouts occur on Mondays and Wednesdays at 3pm Eastern / Noon Pacific.
    4. CLA hub.  https://www.clahub.com/agreements/CA-APM/ca-apm-fieldpack-mongodb (need to create one per project)
    5. EPA 9.7.1 (in release notes) page at https://communities.ca.com/blog/create-post.jspa?containerType=37&containerID=1448.  Release notes need link updated once it is posted.
    6. EPA 9.7.1 link on top wiki page
  3. For each asset posted to GitHub, we’ll need Mary to post a pointer doc (tagged with “field pack”) to the regular APM community.  This is at least until we can get a marketplace/catalog launched.  Other BU’s are having their marketing teams own the catalog.  I don’t think we can do that with current staffing levels.
  4. Document the process for what happens when someone submits a pull request to a repo (we need some sort of code review to take place).  This will sort out any embedded third-party content, export control, and basic code review.
  5. Outline a contributor license agreement (CLA) that anyone who wishes to submit to our repos needs to sign.  Github has an app called clahub which makes this easy once we have text.
  6. When we post the MongoDB stuff to github, we will also need to tag a release and provide a packaged distro that’s ready for people to use.
  7. Another BU is holding weekly office hours on its community in order to make collaboration with devs easier.  Should we do the same?
  8. Once this is all complete, we need to post another handful of existing field packs to bolster the presence.
    1. SOAP Web Services Addon
    2. Communication Extension
    3. UserID Accessor tracer
    4. Baseline Comparison
    5. TIMMonitor?
    6. Hadoop
    7. SQLQueryAgent
    8. Fuse
    9. Mule
    10. Astynax
    11. FullTTDetailsTracer (doesn’t work in new mode)