rudimusmaximus / devflow

A Dev Flow for Google Appscript

DevFlow

A Dev Flow for Google App script. Starter templates, a label scheme, the presentation with many links for reading further, a list of what to install and what it might cost you.

This repository will be used to demonstrate the described 'development work flow' for creating and maintaining Google Apps Script. It will be updated over time to demonstrate various best practices and general demonstrations; some inspired by topics covered in the Totally Unscripted series and posts in the over 20,000 member strong G+ Google Apps Script Community and others by my own private projects.

This addon is intended to be a learning tool whose users can contribute via fork and pull or just follow along.

Anyone can learn to run a test as addon in sheets and quite a bit more via this repository example.

I hope it helps you on your journey and that we will see some contribution by you in the form of discussion or new or improved demos.

Current Release Intent

Please note collaboration is open to all starting with release v1.0.0

Release	Description	Collaboration Status
v0.1.0 "empty shell"	the basic repository with .github folder of templates for contributing, issues, and pull requests and without code	Closed
v0.2.0 "namespace w semantic versioning"	a few files to establish .gs namespace for our work	Closed
v0.3.0 "DevFlow for FEW-D: demo ready"	ready for hands on demo with google's simple addon; will be replaced with true addon for demos during sprint to v1.	Closed
v0.4.0 "make test ready"	automation of applying naming standards during script development and sheets testing See issue #8 to track progress	Closed
v0.5.0 "minimal add-on for sheets prep"	ready for first example demo	Closed
v1.0.0 "minimal add-on for sheets"	Demonstrable, can clone and publish test as addon; a basic sidebar with workflow start and restart and menu with at least one example demo, issues to list out ongoing and upcoming demo ideas, kick off meetings and working sessions to solicit feedback on contributors. - // TODO: list a few issues by hash link reference	Open to all (volunteer today)
v1.1.0 "what's new"	the what's new approach from earlier TU Episode	Open
All Future Releases	star this repo and follow via zen board, fork and suggest, or create issues for requests - // TODO: list a few issues by hash link reference	Open (see 'Zen Board' for all DevFlow)

To Use

See tools section for links. Also, see the section "How to participate".

• Star and watch this repo for ongoing updates
• Install ZenHub extension in Chrome or Firefox from the GitHub Marketplace
• Use the ZenHub task board to monitor flow of issues and to add to the discussion
• Follow contributing guidelines for adding new issues like requests for demos or your own idea
• Practice 'git flow' conventions in your local work; i recommend using GitKraken to initialize the Git Flow for your forked repository when working locally and then submitting a pull request to the develop branch of the main repository. Please make sure you have pulled the latest develop and are not submitting code with conflicts.
• Install GAS Github Assistant for working out of Google's online script editor

# Original Concept and Background ## The entire presentation [Dev Flow by a Process Guy.pdf](https://github.com/rudimusmaximus/DevFlow/files/1130955/Dev.Flow.by.a.Process.Guy.pdf)

As presented in Totally Unscripted Episode 10: Professionalizing Google Apps Script Development

Totally Unscripted: Episode 10 Highlights - Becoming a Google Apps Script Developer Zen Master

My 7m presentation is followed by about 7 min of discussion. Here is the original presentation in a highlight video.

Check out the whole episode if you have time for other approaches and also the whole channel is a great resource for google apps script.
Totally Unscripted Episode 10: Professionalizing Google Apps Script Development

See Also

Our contributing guidelines in this repo's file ".github/CONTRIBUTING.md"

Back Ground Reading (inspiring this dev flow)

“A Successful Git branching model” by Vincent Driessen
“Better Software & Stronger Teams: Project Management for GitHub” by By Matt Butler and Paige Paquette of ZenHub
“Comparing Workflows” by Atlassian
“Make The Product Backlog DEEP” by Roman Pichler
“Post-Agile: A Design Thinking Approach to Software Development” by Tom Dabson
“Semantic Versioning” by Tom Preston-Werner

Implement for yourself

Overview

Tools with links

GitHub - Remote Origin or “truth” repo hosted on private or public repository. With the following standards:

-Git Flow - branch and release tagging approach; see reading list and also GitKraken; enables scalable workflow as you add developers and repositories.
-Semantic Versioning 2.0.0 - referred to and modified in creating our own, consistently applied approach during development and for live releases. Tied to our analytics, release tagging, and code changes.

ZenHub - integrates natively with GitHub's user interface providing a layer of planning without context switching; burndown charts, Velocity tracking, and Release reports powered by live GitHub data. Keeps more people closer to the code.

Work on developer’s local machine

Atom - hackable text editor for Windows, Mac AND Linux.

GitKraken - Git GUI for Windows, Mac AND Linux. Free for open source, educational, non‑profit, or personal use.

Work in developer’s web editor

G Drive Script editor - best in Chrome

GAS Github Assistant - Chrome extension

Costs (confirm on sites)

Google accounts are separate.

Tool	Free	Paid
1 GitHub	public repos	$7/m Developer 25/m Org team w/ first 5 more at 9per
2 ZenHub	< 6 people	$5 user/m on 6 or more
3 Atom	open source	open source
4 GitKraken	sometimes w/o conflict tool	49/yr Ind user 390/yr 10 users
5 Script Editor with 6 GAS GH Assistant	open source	open source
Total	0	Affordable : )

A Special Note on Chromebooks

It is possible to install and run some releases of Linux on a Chromebook that's been put into Developer mode.
Please see "crouton" - Chromium OS Universal Chroot Environment
The cool part here is that you are not dual booting and the Chromebook appears to receive updates and continues to support multiple users. I'm told this voids the warranty on the Chromebook? Worth exploring.

How To Participate in the DevFlow Repository

This section brought to you by a short side project (DevFlow 4 FEW-D) whose site link is Grow With Google Front End Web Development Track - Side Project Visit that for site for meetings, replay links, and contributors as we demonstrate the collaboration phase for DevFlow v1.0.0

[this section to be updated when the project is completed April 11, 2018]

Quick route "i just want to explore the addon demo"

TODO: DevFlow 4 FEW-D

Contributor route "i'd like to try out the DevFlow by participating in the project"

Phase II notes

1. Add your name and GitHub handle to the bottom of this list:

• Rob Goelz @RobGoelz
• Your Name @YourHandle

2. Save this file and commit and push to your origin/develop branch.

3. Submit a pull request from this branch to the development branch.

Implementor "i want to customize DevFlow and make it my own for one or more projects"

[future project]

The DevFlow for FEW-D is a side project to demonstrate collaboration on a GitHub repository designed to socialize a 'development work flow' for creating and maintaining Google Apps Script. Because this repo will include a sheets addon, participants will be able to explore the world of Google Apps Scripting in the useful space of spreadsheets, directly applying recently acquired skills AND laying a framework for much more.

• Apply your CSS, HTML, and JavaScript skills in a new context
• Expand your networks
• Contribute to an open source project
• Learn about Google Apps Scripts and Sheets Addons (quickly)

devflow's Issues

Template for a DevFlow Issue that's code related

Need quick copy of our default issue template used on GitHub and ZenHub

This is the ISSUE.MD file in the .github directory.
Link to file on Master
Link to file on Develop
Contribution Guidelines on Master
Contribution Guidelines on Develop

Final Answer

The markdown file's links are above. To save time when working in GloBoard for a code related issue, the first comment section block below contains the markdown text in Develop as of 2018.05.14. Just:

• Click edit comment block below > copy all > cancel edit
• Then, use the clipboard to paste into a new issue and edit as required per contribution guidelines as linked above

Make generic marketing collateral (images for store and addon)

objective / purpose

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Issue replaced by #45

how to remove this

Describe Phase II deliverables and how we will publish them

add a working list in table view using md

• Finalize list of deliverables to update or add in Phase II
• For each, formalize where they are stored and how included in repository
• Draft Template shells for each and inlcude an issue for each with links to the files

How can we move to ES6 when server side is not?

How can we move to ES6 when server side is not?

See the gist for getting started with GAS in issue #45 about it's support of javascript and while Google has accepted ES6 compliance as a TODO, there is no timeline.

Discussions about transpiling stack solutions for GAS

On google plus
Paul Miller has a nice Es6-shim ready for browser use
Which was modified to work with serverside HERE

Final Answer

Use patterns proven effective and DO NOT TRANSPILE. WHEN we can get a reliable date of support OR a proven and popular solution. Refactor the code!

This will be difficult but will be a good learning point as we learn ES6 and use some older JS in the form of GAS.

Getting more done in GitHub with ZenHub (How to setup for yourself)

@rudimusmaximus commented on Wed Jun 28 2017

Hola! @rudimusmaximus has created a ZenHub account for the rudimusmaximus organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.

---

How do I use ZenHub?

To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.

What can ZenHub do?

ZenHub adds a series of enhancements directly inside the GitHub UI:

• Real-time, customizable task boards for GitHub issues;
• Multi-Repository burndown charts, estimates, and velocity tracking based on GitHub Milestones;
• Personal to-do lists and task prioritization;
• Time-saving shortcuts – like a quick repo switcher, a “Move issue” button, and much more.

Add ZenHub to GitHub

Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @rudimusmaximus.

How to learn Google Apps Script (GAS)?

So How Do I Get Started with Google Apps Script?

A brief strategic overview with links galore.

Final Answer

Try this gist which is now part of a repo "BurningGAS". See below.

• Destroy #42 after reply about sync issue
• Update with sessions and excercises on this topic
• See also our new repo for these GAS sessions "BurningGas"

Implement "What's new" from our demo into this repo's addon

objective / purpose
See #7, implement what we demonstrated into this repository....OR demo what we implemented if demo is created afterward.

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Improve edge scenario in RC script

objective / purpose
Improve edge scenario experience where user attempts to 'make test ready' a freshly updated script (whether new TC or updated RC) that has a short semVer in it and HAS not updated for long semVer.
Test each.
There may be an issue when doing this for a registered release candidate script. confirm

completion checklist

• Discovered in: v0.5.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, complexity, optional estimate
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • tbd
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to a controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Template and guidelines for git commits

objective / purpose
Formalize git commit style for DevFlow.

completion checklist

• Discovered in: 0.2.0
• Resolved/introduced in: n/a issue only no code change
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • Update contributing.md with design notes below
  • Upload a file for use in dev's default git message
  • Add checklist item to default issue checklist from issues.md
  • Add automation to enforce Commit Message Standards see #44
• n/a Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)
• new item (see notes)

POST LIVE:

• n/aBeta Tested - Live to controlled audience  
• n/aCustomer Experience - Live analytics reveal working for customers  
• currently manual as part of PR review and own PR submitter's habits review with issue #44

full pipeline documentation

Overview - describe with history and related items

Referencing style guides for Udacity nanodegree front end web developers, modify contributing.md with an adapted template for DevFlow. These are not automated, so add a check for consistency in the default issue lifecycle.

See these from Udacity course notes:

• Google Javascript Styleguide
• Udacity CSS Style Guide
• Udacity HTML Style Guide
• Udacity JavaScript Style Guide
• Udacity Git Style Guide

Solution Design

Adapted from Udacity Git Style Guide for this DevFlow.

issues.md

We need this new checklist item in the issue lifecycle.

• Pull request review should verify Commits follow style guidelines in contributing.md PRIOR to code merge

contributing.md

Add a section in contributing based on Git commit style guide above.

type: subject

body

footer

WHERE subject is mandatory and the rest optional based on content.

where repo uses git flow and semantic versioning inside codebase namespace.

EXAMPLE modified from Udacity

feat: Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123 [DO NOT use GitHub issue close language if running sprints using ZenHub Here]
See also: #456, #789

What's New Entry

n/a  

Solution Implementation Notes

Note when using GitFlow and our DevFlow label scheme with this new commit style guide, we have three different schemes of classifying changes each with its own purpose and we can make the case for each being equally valid. We will do all three. Listed here for clarity.

GitFlow Branch types	Git Commit subject line types	Issue Label Scheme
feature, release, hotfix	feat, fix, docs, style, refactor, test, chore	The relevant portion of our label scheme would be: DOCUMENTATION, admin-bug, admin-duplicate, admin-enhancement, admin-invalid, admin-optimization, admin-question/assignment Plus the other DevFlow labels as dictated in CONTRIBUTING.MD guidelines

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to a controlled audience

Customer Experience - Re-open and append if issues for customers

• REMOVE signature concept per G+ discussions and testing, also remove sem ver in commits; they are mostly annotated with user. Difference comparisons between tags can show sem ver in files to go further if needed, but this depends on make test ready approach and sem ver in the namespacing.

how to mitigate label destuction

globard edit users can delete labels (not sure if this synchs to github...not yet anyway). Labels may just be 'seeded' form the repo. explore more, create a way to backup to dummy repo using label copy tool.

• Create a private back up repository and use the label copy tool to copy our current set of labels

How can I get access to use the Make Test Ready Process

How Can I Get Access to the Make Test Ready process?

"make test ready" is a recommended, DevFlow best practice process.

Requirements

See #8 ...DevFlow/issues/8 for complete details. Otherwise, follow the steps in this issue and ask for a walkthrough.

Glo Board Team Member - Leads, Contributors, Participants

Using your GitHub account to signup,

• Request read or edit access to this GitKraken Glo board ... Weekly Wednesday Collaboration

With the same Google email from which you will be editing your scripts, get permissions to the two external google sheets required to employ the "make test ready" process. As follows:

• Attempt to access these two tables and request edit access
  • GoListing's master script list for DevFlow DevFlow LIVE - e4.GoListSvc
  • GoListing's analytics table for this process only DevFlow LIVE - e3.Analytics

DevFlow Practitioners - using DevFlow on your own repo

• You'll need to create your own set of tables (two Google sheets) and modify the goList mini service namespace in your repo to point to them.

Final Answer

This issue is your work aid. Follow the steps in this issue and ask for a walkthrough.

• TODO: add video demo from phase II sessions

Remember, it's voluntary to follow this process; however, it will improve your workflow if you are iterating changes on your forked version of DevFlow.

It's really there to make things easier for the developer. Processes take time to get used to, but once you debug live and generate a number of files...you should see the benefits.

Practitioners, you can further customize the target sheet creation to help in your project. Say, include a baseline data set of sheet or sheets in your target google spreadsheet.

After all, it's called Make Test Ready.

example grouping of two

objective / purpose
Demonstrate use of epic to group 2 issues, ideally this grouping would be around the user story.

Practice DevFlow on a Chromebook

objective / purpose
Demonstrate DevFlow being used on a Chromebook.
From readme.md's special note on chromebooks:
"It is possible to install and run some releases of Linux on a Chromebook that's been put into Developer mode.
Please see "crouton" - Chromium OS Universal Chroot Environment
The cool part here is that you are not dual booting and the Chromebook appears to receive updates and continues to support multiple users. I'm told this voids the warranty on the Chromebook? Worth exploring."

Please provide an example of this working and describe how you did it.

completion checklist

• Discovered in: pre-v1.0.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

wip

What's New Entry

No change this repo, this issue is documenting an answer to a question.

Solution Implementation Notes

wip

Developer Testing- Disposable Alpha and Release Candidate

n/a

Live Testing - Beta live to controlled audience

n/a

Customer Experience - Re-open and append if issues for customers

n/a

Modify DevFlow to account for multiple release candidate scripts

objective / purpose
we need to check our overall process as we designed for one registered script to publish to a domain; let's expand to allow for publishing to groups, unlisted links, domains, and market.
Establish guidelines, see discussions. Dedicated scripts for each, but review and document.

completion checklist

• Discovered in: v0.5.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • Add new enums for additional script IDs as listed in design
  • Flag the topic as something for workshops later
  • Update issues and cross link that mention this for stated domain codes and registered scripts
  • Update stated domain code logic which is in get literal function
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to a controlled audience
• Customer Experience - Live analytics reveal working for customers

full pipeline documentation

Overview - describe with history and related items

see working notes Registered scripts (IDs by type), make test ready (current stated domain)

Solution Design

Create new enums:

• create and reserve three enums for three total (two more) standalone script IDs to register for each domain the repo will be published from as follows where ABC is
  • ABC_REGISTERED_SCRIPT_ID_LNK - to unlisted install link
  • ABC_REGISTERED_SCRIPT_ID_GRP - to private group
  • ABC_REGISTERED_SCRIPT_ID_MKT - to web store

Modify logic here to account for new enums for registered scripts (additional or logic)
see Add-on/Con-stants-structs-tainers.gs

/**
 *  Returns the requested hardcoded literal as a string when logic is required
 * to determine. otherwise, use appropriate Enums.
 *
 * @param  {string} requestedField - field name of hard coded value for curent version of CF Maker
 * @return {string} responseString - the value associated with the requested field name.
 */
function getLiteral(requestedField) {
  var response = "";
  switch (requestedField) {
    case "currentStatedDomainCode":
        //STATED DOMAINS are unique to the domain the script is deployed from (assumed same id when published via developer dashboard)
        // if not set at deployment, undregistered scripts will be treated as a disposable alhpa, meaning the script is a test copy and not a script file that gets pushed to a production domain (ie published to the store)
        var scriptId = ScriptApp.getScriptId();
        if (scriptId === RCM$.ThisAddon.Enums.RCC_REGISTERED_SCRIPT_ID) {
            response = RCM$.ThisAddon.Enums.REDCROWCONSULTING_STATED_DOMAIN_CODE;
            break;
        } else if (scriptId === RCM$.ThisAddon.Enums.RCM_REGISTERED_SCRIPT_ID) {
            response = RCM$.ThisAddon.Enums.REDCROWMETHODS_STATED_DOMAIN_CODE;
            break;
        };
        response = RCM$.ThisAddon.Enums.DISPOSABLE_ALPHA_STATED_DOMAIN_CODE; //is unrecognized and likely a "disposable alpha script which could be in any domain and if so the user email will be a developer and give it away; note: this value is checked in go listing so change with care
        break;
    default:
        response = "Requested field not defined among literals.";
        break;
  } //end switch
  return response;
} //end getLiteral

What's New Entry

Solution Implementation Notes

Completed for two domains as follows and will test to LNK from RCM domain in phase II project.

Developer Testing- Disposable Alpha and Release Candidate

For existing registered scripts,
From @rcm

Scenario	Results	Comments
1. unregistered newly created, standalone script	created script and sheets target named DevFlow TC - 0.5.4-registeredScripts.3 - Wed Sep 05 2018 12:36:11 GMT-0500 (CDT)	able to test, no issues, found edge case 1
2. registered MKT	a. with long semVer renamed script and created identical target sheet DevFlow RC - 0.5.4-registeredScripts.3 - Wed Sep 05 2018 12:43:36 GMT-0500 (CDT) b. with short semVer, reanamed script with no target sheet as expected (see notes)	a. able to test, no issues b. no target to test and not yet published, no issues 2
3. registered LNK	a. with long semVer b. with short semVer	a. able to test, no issues b. able to test, no issues

Notes

[18-09-05 13:06:19:561 CDT] Sheet is at https://docs.google.com/a/redcrowconsulting.com/spreadsheets/d/1hKLgQHLoSvKcUGYBbcVJEcigwIuI_MbdAFUniEjVRYM/edit
[18-09-05 13:06:19:562 CDT] Completing successfully.
[18-09-05 13:06:19:562 CDT] Tracking analytics...
[18-09-05 13:06:20:187 CDT] STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1pvIALzhxpkzV1MlgNX4Q1qtIBDD9LD4fh0HfXWnYwNcsjFLlYIIFH3WP/edit?usp=drivesdk
SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible

Naming your script 'Unexpected goListStatus in renaming. Investigate.'

• CREATE new issue for function createStandardDescription (goListStatus) {
  , see goList status created "i think it's blank" in this scenario
  review and update logging to include this name/message and add instruction to start by checking semantic version. separate issue and does not stop this one. workaround, user training, mark resolution II and Phase II in case handled later.

From @rcc

Scenario	Results	Comments
1. unregistered newly created, standalone script	pass	pass
2. registered MKT	pass	pass
3. registered LNK	n/a	n/a

Table results make test ready

Live Testing - Beta live to a controlled audience

Customer Experience - Re-open and append if issues for customers

Footnotes

1. Potential issue or training note. When pulling into new script and semVer is short, the make test ready will stop as follows:
   [18-09-05 13:06:16:664 CDT] Starting analytics...
   [18-09-05 13:06:16:665 CDT] Setting 'GoNoGo Status' to 'N'...
   [18-09-05 13:06:16:724 CDT] Checking if already goListed...
   [18-09-05 13:06:17:395 CDT] Not listed. Creating new goListRcd...
   [18-09-05 13:06:17:401 CDT] Creating standard name...
   [18-09-05 13:06:17:402 CDT] Renaming script to:
   'Unexpected goListStatus in renaming. Investigate.'...
   [18-09-05 13:06:18:504 CDT] Writing goListRcd...
   [18-09-05 13:06:18:745 CDT] Priming script properties...
   [18-09-05 13:06:18:822 CDT] Creating matching target Sheet for testing... ↩

2. log was as follows
   [18-09-05 12:47:27:808 CDT] Starting analytics...
   [18-09-05 12:47:27:809 CDT] Setting 'GoNoGo Status' to 'N'...
   [18-09-05 12:47:27:861 CDT] Checking if already goListed...
   [18-09-05 12:47:28:425 CDT] Not listed. Creating new goListRcd...
   [18-09-05 12:47:28:430 CDT] Creating standard name...
   [18-09-05 12:47:28:431 CDT] Renaming script to:
   'DevFlow'...
   [18-09-05 12:47:29:178 CDT] Writing goListRcd...
   [18-09-05 12:47:29:364 CDT] Priming script properties...
   [18-09-05 12:47:29:461 CDT] This is a production deployment. No matching test sheet required.
   [18-09-05 12:47:29:461 CDT] Completing successfully.
   [18-09-05 12:47:29:462 CDT] Tracking analytics...
   [18-09-05 12:47:30:681 CDT] STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowmethods.com/d/11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K/edit?usp=drivesdk
   SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible ↩

Analytics expansion wave - add stackdriver and review logger.log usage

How can we Automate git commit message standards enforcement

How can we automate git commit message standards enforcement?

Open for suggestions. Can this be done in the repo so copies get the enforcement? or is this a per machine basis?

Review this on githooks

This is one answer but githooks are unique to local user repo and do not persist or propogate; still could offer as template to help submitters?

Review what happens to life of commit messages as the change moves through the fork and pull contribution lifecycle.
https://support.gitkraken.com/working-with-repositories/githooks

Final Answer

TODO

"make test ready" automates some naming conventions

objective / purpose
"make test ready" - automation of applying naming standards during sheets addon script development and sheets testing 'test as addon'

completion checklist

• Discovered in: n/a pre v1.0.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • Document criteria and meets specifications rubric
  • Design intended instructions (developer steps) for developer use in about 10 steps
  • Create INSTRUCTIONS.md file as described by design
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)
• In working this, we also refactored. Completed #5, but need to update that issue

POST LIVE:

• Beta Tested - Live to a controlled audience
• n/a Customer Experience - Live analytics reveal working for customers

full pipeline documentation

---

Overview - describe with history and related items

Since DevFlow recommends creating some of your own automation to improve standards where possible, we felt the need to design something around semantic versioning. When 'testing as addon' from a standalone script, a target sheet has to be selected when defining the test. Over time, you generate lots of sheets. Additionally, many scripts can be created since we have the ability to pull from our origin repositories.

The key requirements are as follow:

Criteria	Meets Specifications
1. Register and track any number of scripts	a. Ability to register a script ID as the official script from which an addon would be published, b. Document short 'stated domain codes' such as @rcc, @rcm for the registered scripts; all other scripts should have a stated domain code of "DA!" for 'disposable alpha';
2. Script and Target Sheet Naming	a. ability to programmatically rename script, b. Create new target sheet using same naming scheme as script, c. The name follows a standard of derived from rules base on addon name, semantic version, long name designating branch and iteration with timestamp and designates release candidate, test copy, or ready as addon name only' (this is because when script is published the name becomes the name of the addon in the menu)
3. Go No Go	a. provide a function to test file was 'go listed' by make ready in documented sheet (to be used on start workflow in future) b. must persist data not otherwise available at runtime so can run goNoGo for a user if so desired (see properties services)
5. Special cases	a. does not allow for duplicate make ready on scriptID&semVer combination

Solution Design

Stated Domain Codes

These are in the go list table and are used for the naming logic. Registered domains get the "@" symbol followed by a short code -- so ["@"]+["unique short 3 or 4 digit code"]
The only exception is "DA!" which is reserved for all unregistered scripts.

Start with these three:

• RCC - RedCrowConsulting.com G Suite domain registered to publish
• RCM -RedCrowMethods.com G Suite domain registered to publish
• DA! - see requirement 1.b.

Registered means we enum the script id, assign it a domain code, and check for it in the logic.

Go Listing for Make Script Test Ready

Make test ready runs functions in a namespaced goListSvc. 'GoListing' is achieved via mini-service here in a namespace and run prior to testing or deployment post changes;

• includes references to external G sheet for the persistence of script information not available during user run time.
• In a 'deployment area', a make test ready function should call the go listing methods. This is done by the person making changes with edit access to the script.
• Only contributors should have write access to the tables that run the 'goListing' and the 'analytics' for this miniSvc
• The 'GoListing' process seeks to mostly automate a manual checkpoint to enforce semantic versioning and other naming conventions" that make our testing and clean up easier and more useful. Overall, this improves the quality of our 'Red Crow Dev Flow' with various rules and standards to enforce"
• Note: deployment consists in publishing to test in target sheets from registered and temporary scripts,
• for production users, it consists in versioning the script and publishing the registered script to the Google developer dashboard
• Registered means code knows the scripts and all externals required like sheets, 3rd party webhooks, others as needed
  The golisitng service should allow for testing requirement 3, and listing new entries into a table like this:

DevFlow LIVE - e4.GoListSvc

External google sheet with access for contributors wishing to employ the "make test ready" process.
Special note: the GMT Stamp is in GMT, but the created file name is in offset GMT based on the local server time zone. This is so the developer can recognize the time on their new script names and target sheets.

Y	M	W	GMT Stamp (-5CDT,-6CST)	Active User	Stated Domain	AddOnVer	Script ID	Go List Status	Script Name	Script URL
2018	5	21	2018.05.26 04:19:09.000 AM	[email protected]	@rcc	0.3.0	1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi	READY	DevFlow	https://script.google.com/a/redcrowconsulting...
2018	5	21	2018.05.24 07:08:11.000 PM	[email protected]	DA!	0.3.0-makeTestReady.14	1j11oy1rKWZrJttYBpCFjrIHk4Xd_LVO1t7PO4LL11WSv0Qa8i9YcvrZf	TEST COPY	DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 14:08:11 GMT-0500 (CDT)	https://script.google.com/a/redcrowconsulting...
2018	5	21	2018.05.24 05:35:52.000 AM	[email protected]	@rcc	0.3.0-makeTestReady.14	1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi	R CANDIDATE	DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:35:52 GMT-0500 (CDT)	https://script.google.com/a/redcrowconsulting...
2018	5	21	2018.05.24 05:32:46.000 AM	[email protected]	DA!	0.3.0-makeTestReady.14	1dL0u0lOuCdakopBqUQSbaAr1ot0lBcAtBO8Y4djtA-xktgDaxL1JsAs4	TEST COPY	DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:32:46 GMT-0500 (CDT)	https://script.google.com/a/redcrowconsulting...
2018	5	21	2018.05.24 05:25:18.000 AM	[email protected]	@rcm	0.3.0-makeTestReady.14	11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K	R CANDIDATE	DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:25:18 GMT-0500 (CDT)	https://script.google.com/a/redcrowmethods...

Go List Status on the table

• Test Copy
• R Candidate
• Ready
• Unexpected will throw an exception and not write goList a record

Naming rules

Test Copies

Get the following standard name
Format:
[USER_FACING_NAME_OF_ADDON]+' TC - '+[CURRENT_ADDON_VERSION]+' - '+[newDate in GMT offset into local server time zone]
Example:
DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 14:08:11 GMT-0500 (CDT)

Release Candidates

Get the following standard name for registered scripts with novel semantic versions (previously unlisted per req 5.a.)
Format:
[USER_FACING_NAME_OF_ADDON]+' RC - '+[CURRENT_ADDON_VERSION]+' - '+[newDate in GMT offset into local server time zone]
Example:
DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:35:52 GMT-0500 (CDT)

Ready To Be Directly Published

Get the following standard name
Format:
[USER_FACING_NAME_OF_ADDON]
Example:
DevFlow

The reason here is that the published addon will list the script name in the store and in the addons menu.

The developer steps would be as follows:

• Move these into a new INSTRUCTIONS.md file in the root of the project next to the README.md

How to Iterate this Code Using DevFlow and "Make Test Ready" Process

Test as Add-on from Google Apps Script Web Editor

1. Fork The repo github.com/rudimusmaximus/DevFlow
2. Clone and make changes to a new branch off of your copy of Develop or Master (per Git Glow - fix, feature, hotfix rules). Hint: likely Develop: feature/newBranchName
3. Update Semantic Version per guidelines in the file named G/gs/namespace_DEV$_top_level.gs. Set the DEV$.Developer.Enums.CURRENT_ADDON_VERSION value to something like "0.3.0-newBranchName.1" Hint: you can just make this change and iterate on the web copy if you like which may happen as you debug.
4. Make your code changes and commit them using git commit message guidelines; push this branch to your remote 'forked repo'
5. Open a new standalone script; save it once and then, from the web editor, pull your code from this new branch using 'Gas Git Hub Assistant' or any other method ('Clasp' or 'Copy and Paste'). Save again.
6. Activate the latest Drive advanced service (you only do this once per script you want to run make test ready in)
7. Run make test ready. Refresh your browser to see renamed script using DevFlow standard.
8. Setup a test choosing the recently created sheet (created by step 7 w naming standard)
9. Check your code in the addon running in test on your target sheet named the same as your script
10. Iterate as needed and each sem ver change requires a repeat of steps 7,8,9; you can push any iteration along the way or just the last one to your origin branch (using GAS GitHub Assistant). Then, you can pull from origin as necessary.

DevFlow should now have same name scripts and target sheets iterating on Semantic Versions.

What's New Entry

n/a

Solution Implementation Notes

Key lessons learned

• "make test ready" will be a recommended, DevFlow best practice process. We will not enforce in the addon's start workflow mechanism BECUASE we want casual enthusiasts to be able to fork and pull, clone and run a test as addon locally without membership to globoard or edit access to the two external files required for that process.

• See issue 48 for how to implement yourself

Advanced Services

• TODO: Document how to setup advanced service and which one(s) are required

A Note on Analytics

StackDriver

We will leverage the built-in StackDriver analytics to capture within a 7 day? window all execution times and exceptions.
That said, consider a review in phase III or sooner if time permitting, to review the analytics used in the goList 'make test ready' process.
We may be able to leverage approach to generate objects we pass to stackdriver logging and not to any table.

• TODO: Stackriver Logging link to issue and mark phase III. With Stackdriver Logging, You can log strings, formatted strings, and even JSON objects using the functions provided by the Apps Script console service. Let's test passing JSON for the mini service namesace and the analytics we write for goListing.

Generated times

Review what we use and if we should move to Universal Time or other OR if we can/should match stackdriver's approach. Must allow for people around the world contributing.

• TODO: timestamps in externals link to issue and mark phase III

GoListing's analytics table

DevFlow LIVE - e3.Analytics

External google sheet with access for contributors wishing to employ the "make test ready" process.
Special note: the GMT Stamp is in GMT.

Y	M	W	GMT Stamp (-5CDT,-6CST)	Active User	Stated Domain	Add On Ver	Current LoB	Step	Sub Step - by click, action, scenario scheme	D secs	Exit Memo	S	E	External Output	Ux count	Ux secs	Net secs
2018	5	21	2018.05.26 04:19:10.000 AM	[email protected]	@rcc	0.3.0	Repurposed for DevFlow	Go list a script	developerAction: G Web Editor > 'goListTheCurrentScript'	1.927	STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible	1	0	Event log entry	0	0.000	1.927
2018	5	21	2018.05.24 07:08:12.000 PM	[email protected]	DA!	0.3.0-makeTestReady.14	Repurposed for DevFlow	Go list a script	developerAction: G Web Editor > 'goListTheCurrentScript'	2.404	STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1j11oy1rKWZrJttYBpCFjrIHk4Xd_LVO1t7PO4LL11WSv0Qa8i9YcvrZf/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible	1	0	Event log entry	0	0.000	2.404
2018	5	21	2018.05.24 05:35:55.000 AM	[email protected]	@rcc	0.3.0-makeTestReady.14	Repurposed for DevFlow	Go list a script	developerAction: G Web Editor > 'goListTheCurrentScript'	2.55	STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible	1	0	Event log entry	0	0.000	2.550
2018	5	21	2018.05.24 05:32:47.000 AM	[email protected]	DA!	0.3.0-makeTestReady.14	Repurposed for DevFlow	Go list a script	developerAction: G Web Editor > 'goListTheCurrentScript'	2.206	STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1dL0u0lOuCdakopBqUQSbaAr1ot0lBcAtBO8Y4djtA-xktgDaxL1JsAs4/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible	1	0	Event log entry	0	0.000	2.206
2018	5	21	2018.05.24 05:25:20.000 AM	[email protected]	@rcm	0.3.0-makeTestReady.14	Repurposed for DevFlow	Go list a script	developerAction: G Web Editor > 'goListTheCurrentScript'	2.4	STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowmethods.com/d/11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible	1	0	Event log entry	0	0.000	2.400

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

n/a

Define initial releases

objective / purpose
Create some ZenHub releases and initial epics to collect issues for planning some work.

completion checklist

• Discovered in: pre-v1.0.0
• Resolved/introduced in: v0.2.1
• Changes Listed (mark each member as completed update as needed)
  • Socialize list of initial releases
  • Create issues to sketch the work and follow DevFlow (GitFlow+ZenHub+semantic versioning)
  • Update readme.md with the final release intent
  • Iterate to v0.2.1 "update release intent in readme.md"
  • Create a few epics and start development with git flow shake out
  • Gather feedback

full pipeline documentation

Overview - describe with history and related items

This is a planning item for discussion.

Solution Design

Current Release Intent

v0.1.0 "empty shell" - the basic repository with .github folder of templates for contributing, issues, and pull requests and without code
v0.2.0 "namespace w semantic versioning" - a few files to establish .gs namespace for our work
v0.3.0 "make test ready" - automation of applying naming standards during script development and sheets testing
v1.0.0 "minimal addon for sheets" - Demonstrable, can clone and publish test as addon; a basic sidebar and at least one function to demonstrate changes, workflow start and restart
v1.1.0 "what's new" - the what's new approach from earlier TU Episode
all future releases - star this repo and follow via zen board, fork and suggest, or create issues for requests

Host README.md and CONTRIBUTING.md images

objective / purpose
Host images for the README.md file starting with the original presentation for this repository.

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: v0.1.0
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • update for presentation link and in readme.me
  • keep open on ice for ongoing updates as needed
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

From the initial presentation cover page

The entire presentation

Dev Flow by a Process Guy.pdf

others from pres

CONTRIBUTING.md Images

Issue Label Scheme

Move existing google demo to be called by new function created in top level sidebar

objective / purpose

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Establish analytics for addon usage

objective / purpose
establish analytics that account for TC, RC, and our listing if placed into marketplace
may need to cover the different kinds of logging in this or separate
discuss
completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Create top level sidebar as welcome

objective / purpose

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What we have with v0.5.0.

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Demonstrate subteam fetches ie working on same feat branch

Question In a Short Phrase

do this both in cli git and gitkraken

Subsections as needed

Add any history or detail in this subsection. Add others if needed

Final Answer

update

Expand Analytics in waves of changes

objective / purpose
We have sheets analytics in our make test ready / goListing process. expand it's use so we can capture start, restart, and demo starts, ask demos to include with same pattern or as improvement in phase II.

Functional requirements for this epic

Criteria	Meets Specifications
1. this	a. subtopic b. another sub topic
2. that	a. subtopic b. another sub topic
3. this	a. subtopic b. another sub topic
4. that	a. subtopic b. another sub topic
5. this	a. subtopic b. another sub topic

---

Overview - describe with history and related items

cover

Template for a Q&A Question

Instructions

Starting in the Contributor, Participant, or Spectator column:
1 Please ask your questions in a New Issue and paste the Outline from the next comment block below. Add detail as necessary and include issue numbers by # notation if there are any.
2 Assign the following labels to your new issue:

3 Assign a best guess at the Complexity of your question from the following options:

4 As the question is worked, add any tasks if we need to track completion or divide and conquer
5 When the group is satisfied with an answer, update the Final Answer section making sure tasks if any are completed.
6 Add the Label "Fixed"

7 DO NOT CLOSE the issue as we want to see them in glo boards
See GitHub's Guide for advice on using markdown styling.

"What's new"

objective / purpose

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Analytics expansion wave - more of our sheets based

initial setup v0.1.0

objective / purpose
the basic repository with .github folder of templates for contributing, issues, and pull requests and without code
completion checklist

• Discovered in: pre v1.0.0
• Resolved/introduced in: v0.1.0
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • setup image and pdf hosting issue for readme and contributing work
  • setup repo with readme and .gitignore
  • setup label scheme and contributing.md
  • test GitFlow in GitKraken and create v0.1.0 tag as well as Develop branch on GitHub
  • update default ZenHub pipeline per contributing guidelines
  • start pushing issues to work on more releases

full pipeline documentation

Overview - describe with history and related items

see presentation notes in readme.me and contributing.md

What should i know about GK GLo to GH Sync

What to know about GitKraken Glo to GitHub sync

We are using ZenHub for code sprints and Glo for this project work to 'Shake Out' the dev flow process. This means using the label scheme and documenting along the way - especially as glo is a young product.
Phase II will use a Glo board to facilitate discussion around templates and deliverables for the repo and to get ready to use ZenHub in live sprints in phase III and trial sprints in late phase II. The Glo boards will facilliate our Weekly wednesdays.

What glo is supposed to sync

GitKraken Glo Challenges

5/11/18 pm - Had a long chat with support, they are contacting developement and documenting some qeustions:
1 board out of sync with github issue
2 assignments to issues
3 making more issue fields available
More updates to come, link to chat part 1 here
Link to chat part 2.

globoard users and label interactions

Looks like some changes like labels are posted in github history as the admin owner of the globoard.
Participant and other history changes are noted by github username. Explore other differences. Basically, there are card activities and card actions that stay on the globoard in terms of viewing the log of activity. Many of these don't exist in GH.
As long as we are logged into our glo-boards, we are in sync with latest (noted)
Labels are seeded from repo when synced board is created but nature of sync with deletes and edits is unclear.

GitHub Considerations

participants, contributors, collaborators - Assignments

A potential workaround without giving write access to the repo!

old working notes TODO: review

Move assignments to GH manually by someone with write access to master repo (possibly our two leads). IF we can confirm that contributors can be assigned issues after their changes make it to the default (in our case master) branch. Appears the case with @DevFlow-Developer1 testing with @RobGoelz. if so, we just need to have globoard users make modest readme.md contributions and get those into master. maybe by sprint time the glo sync will work for assignments. see last block of notes and update, more testing to come.

• update chat transcript link
• document board out of sync lessons
• test assignment to issue scenarios
• document issue fields from gh, zenhub, and user defined

Final Answer

TODO: update. Current approach is branch protection settings see #31 and to keep assignments inside of glo board UNTIL we are ready for sprint work.

Latest Correspondence from GitKraken

email chain

GitHub's "good first issue" should be added to suggested label scheme

objective / purpose
Good addition to label scheme whether public or private repo. If private, maybe good suggestion for new team member.

completion checklist

• Discovered in: 0.2.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • update issue
  • update md mentions
  • link to this in my other repos

POST LIVE:

• Beta Tested - Live to controlled audience  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

How to best set Branch Protection Settings for this project

because this repo is the public repo of a private user (not org), we need better access to the issues to collaborate on them.
SO, we are using glo boards. With some risks. See #32
And also review how histories are updated with changes to issue summary line/title.
Globoard users with edit access CAN EDIT EACHOTHERS comments.

• Set initiial protections for Develop and Master
• Review as group during sprints
• Document in a phase ii deliverable or update to existing repo
• document rules around who can approve in review

Create minimal addon for sheets

objective / purpose
Demonstrable, can clone and publish test as addon; a basic sidebar and at least one function to demonstrate changes, workflow start and restart, placeholder menu items for intended demo list

completion checklist

• Discovered in: v0.4.0
• Resolved/introduced in: v0.5.0
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • Create overall icon and required promo tiles
  • Create menu function that sets menu based on calling context string: 'onInstall','onOpen', ....see private notes for scheme and functions, document design
  • Integrate with #50 for welcome sidebar
  • Test across authorization flows
  • @rcc use maketestready to test Release Candidate
  • @rcc create store listing trying out new store dashboard, publish to domain and test
  • @rcm create store listing, Publish to anyone with link and test
  • iwik do you need a separate script to publish as link, to group, to domain? if so well just test registering more than one to same stated domain code. likely separate is easiest but uses up listings...can same move from as link to domain to store?
  • Demo to #51 @RobGoelz
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Nice article. I use DevFlow to resolve his item 1 but a nice article. I will point out his comment on material design is about android add-ons and NOT standard GSuite add-ons which have their own style guide -- see apps script add-ons style guide

See article on auth flow and file naming conventions for script separation "6 deadly sins"

Also, see comments in clasp issue on gs to js describing files approach for add-ons. In these notes, the contributor describes their file naming approach: "
Also about the client javascript, we currently have this sort of typical structure (locally):
─ main.gs
─ someLib.gs
─ sidebar/
└─ index.html
└─ clientCode.js.html
─ dialog/
└─ index.html
└─ clientCode.js.html
"
Review that against the 6 sin article and also see #5 #29 #28 but periods in file name is ok TODO:test
TODO:

• update #5, #29 is fine, per #28 "Removed periods from folder names - sometime GAS assistant can recognize this and ignores these files as being of type not relevant"
  SO RULE is not to use periods in the folder names BUT in file name is ok.

Solution Design

Final Folder, File, and Namespace organization

Only .gs And .html

These are the files that Gas GitHub Assistant will pull or push to hosted repo (currently GitHub)

All File Types

and

Promotional Tiles

See also #49. Here, are the promo/marketing tiles and icon options for our top level addon.

Original files in G Drive

https://drive.google.com/a/redcrowmethods.com/file/d/17TqcXiqBniFhy4Tk3tb4Gcq3iHY-GPCy/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1J8CL--1UWWcp5_MoYuafrDhbQaoiv-wQ/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1fNTRacjyoAnuawbRyHRs-iZwMO2Lz_-u/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1nh72Vvd2wt0hLuf9ls873PHwgqzDdaVr/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1rP_t4Ehg7OMSWMeX2dH5Z_lg_8xP6Vw0/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1tKXOw9q6lGitMrTQNZH4BH3q39XM7b4F/view?usp=sharing

Uploaded files with G Hub Links

What's New Entry

n/a yet

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Add more from presentation to readme and contributing

objective / purpose
Add more from presentation into the readme and contributing files
completion checklist

• Discovered in: v0.1.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • in readme, mention where to find contributing
  • in readme, Add links from presentation background reading "inspired by" slide
  • in readme, Required tools and costs diagram, table, links and writeup
  • Guiding principles and best practices from slide nine
  • Semantic Versioning
  • Things to watch out for
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

full pipeline documentation

Overview - describe with history and related items

Solution Design

See changes in readme and contributing.md files and original presentation is design.

Create templates for when using globards

issues, see #21, 35, 43

• Template for a Q&A Question is in #35
• Default issues not created in ZenHub or GitHub; use ISSUES.MD in a new issue and link here
• Git Commit messages

Demo javascript patterns in GAS

objective / purpose
Demo to walk through examples of the .

Working notes

see also https://mashe.hawksey.info/tag/google-apps-script-patterns/

Solution Design

Establish basic namespace w semantic versioning

objective / purpose
A few files to establish .gs namespace for our work with enums to handle semantic versioning
completion checklist

• Discovered in: pre v1.0.0
• Resolved/introduced in: v0.2.0
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • folders for code org
  • namespace file

full pipeline documentation

Overview - describe with history and related items

This is pre v1.0.0 release work.

Solution Design

Gist for example nested namespace in an addon

more changes

• Update folder structure so can have one main welcome and any number of demos
• Test with "make test ready" changes for semantic versioning inside nested namespacing
• Improve logging.log to use stackdriver console
• add example namespace function for logging to demonstrate
• Update issue with changes here since this is pre-release including new screenshots for folders when #8 is complete
• add rest of pipeline documentation as during implementation we con document quirks of namespace in GAS addons such as how we can call menu items so we can send parameters if we like, optional paramaters, and default values

How should we document best practices with the tools we are using?

objective / purpose
How to document best practices with the tools we are using. For example, git hooks or commit templates in GitKraken, packages and themes in atom, etc.

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

working list

• repo wiki
• as issues with md docs inside repo
• other

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Answer Wednesday Participant Questions

Shakeout and demonstrate semantic versioning in git flow

objective / purpose
CONFIRM and REVIEW for accuracy against git flow practice and git kraken implementation by running demonstrations on a test repository while monitoring the git directly.

completion checklist

• Discovered in: pre-v1.0.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

How can I keep up with Weekly Wednesdays I can't attend?

How to keep up with Weekly Wednesdays

Need a place to catch up.

Final Answer

We are driving to put 'everything' into the repo and keep up to date via Glo Board.
Here is a direct link to the web app for this board
Notes from meetings will be logged Markdown style in updates to this issue here in chronological order.
Meetings will be on Wednesdays and either be a working session, a general session or combination of the two:

• Working Sessions by topic
• General Sessions for demonstrating the state of the project

Key Completed:

• Kicked off lead only meetings, kicked off weekly meetings
• Start a logging issue for Weekly Wednesdays; #46 this issue
• Send glo board invites to rest of email list that have not updated for phase II but have left subscription on
• GAS basics parts 1-3: cover more examples as described in the last section of Gist linked to issue 45
• Conduct first and second general sessions
• Conducted General Session II (and GAS part 3 working session)
• Started a timeout on July 12
• Aug 15, 2018 General Session III CANCELED
• Aug 22nd resume weekly Wednesday working sessions - more GAS and addon prep
• started ZenHub SPRINT 1 - Aug 22 - Sep 5 14day sprint
• Demonstrate release push with develop branch demo of make test ready
• Standup basic published to shareable unlisted link
• Sep 12, 2018 General Session 4 - Basic addon ready demo, demo ideas

Key Upcoming:

• Sep 19 - Claim or lose a demo by commenting on issue #65
• Dec 12 - Phase II Closed - Demo, lessons learned, comments on phase III
• tbd - Phase III Open Sprints as scheduled
• Best Practices Sprint - Open source facelift on our readme and repo to model collaboration and update everything after lessons learned, readme.md, issues and epics for updated release intent

Overall Plan dates

Leads with access to maintain a high-level plan. The main dates are above.

Latest Plan Extract

Our website hosts the latest and most detailed publically available plan is on our site.
See our project site

Chronological Notes

Abbreviations:

• WS Weekly Wednesday Working Session
• GS 2nd Wednesday General Session

2018.05.09 WS-Planning Meeting

• No recording

2018.05.16 WS-Overview and GAS Basics part one

• Overview of boards and approach with a review of the current timeline.
• Recording of the session is available here at this link.
• GAS basics covered outline of this Gist mentioned in issue #45

2018.05.23 WS-Debug and tested make test ready no recording

• Make test ready is develop branch at the next session we will test it and move it to production live; read about it in issue 8
• Two great tools used to create issue 8 documentation were:
  • Dillinger as recommended by Udacity
  • Markdown Table Maker for Google Sheets

2018.05.30 WS-Updates, learnings, Make Test Ready Demo

Check out the replay here

Agenda

• Project schedule udpates
• Out of Sync workaround
• Linking to other issuses on GloBoard
• Deliverables for phase II
  • See #33 ...DevFlow/issues/33
• Make Test Ready Process
  • See #8 ...DevFlow/issues/8
  • See #48 ...DevFlow/issues/48
• cool articles:
  • CSS Grid vs Flexbox
• udpates on GitKraken Glo board software
  • no action required; just added pdf of correspondence so you can see how we campaign for features we want. Sometimes, it's better to influence young or responsive products to get what you need rather than build your own tools. Correspondence
  • See also #40 ...DevFlow/issues/40

2018.06.06 WS-Make Test Ready Release, phase II deliverables, prep for general session 1

No Recording

Agenda with notes

• make test ready was released in DevFlow v0.4.0 and is in both Develop and Master branches.
  • we are working out an issue discovered in testing around newly re-named scripts; we will make an edit to logging and the process write-up. They will go in as a 'hotfix' to demonstrate that too. We will demo result in our first general session on June 13th.
• General session I June 13, 2018, 1 of 5 in Phase II
  • In each of these sessions, we will present a presentation on the approach and deliverables highlighting updates since the last meeting
  • Demo make test ready
  • updates to Deliverables for phase II
    • See #33 ...DevFlow/issues/33
    • TODO: finish adding a list of deliverables
    • TODO: generate issues for each of these deliverables
• This week's Cool links:
  • Placeholder Image Tool "Quick & simple image placeholders" you can set format, text color and size in a single URL, use in code or to generate what you need. change to https if needed.
  • Insert Icons for Google Slides
  • Insert Icons for Google Docs
• Next Week: So far, we've worked out of emails and issue updates on the repo via glo board. BE ON THE LOOKOUT for placeholder meeting invites for each of the 5 monthly general sessions.

2018.06.13 GS-General Session I and Special Guest

Agenda: special guest from at&t scheduled to join us!
1 State of the repo and release updates
2 Phase II our "deliverables" updates - repo documents to model the DevFlow approach
3 State of the Demos updates - when started
4 Session Highlight - Make Test Ready process, Glo Boards show and tell demo with lessons learned
5 Q&A - Open questions and hands-on

Notes:
Here's the presentation PDF with live links AND the recorded session of 1hr30m.
Hear from our at&t guest at the end after the demo.

2018.06.20 WS-GAS Basics Part 1

Recording Link

Agenda with notes

• GAS Basics working sessions to try out GAS on sheets data; some of these could be turned into demos of successful "GAS patterns"

  • Each week for a series of weeks will cover some GAS basics and share the sheet with its script as well as the recording, so you can follow along and explore.
  • We recommend making a copy of the provided files and then working from there. If you want to make comments on the file, just add comments in the sheet we link you to.

• Topics covered include

  • Update Multiple Values
  • Manipulate Disjoint Ranges
  • joint discovery based on interest and time
    • on open build menu calling these
    • others? practice using and presenting from editor
  • dates - cancelling working session on Aug 1st

• This week's Cool links:

  • Working Sheet File w Script
  • How Fast is Realtime? Human Perception and Technology
  • JavaScript engine fundamentals: Shapes and Inline Caches
    • the original tweet about the article has a rich discussion see Twitter post
  • The One Tab chrome and firefox extension save 95% of memory when you have too many tabs open; use as intended
  • Digo Chrome Extension extension for Diigo.com tool

• Unassigned Action Items: research items, problems to solve, notes, special items

  • Other DevFlows from GDEs we gave feedback (and got mentioned) in a google developer expert's DevFlow for an org team. This G+ post shows him listing a document for feedback and the document itself has comments you can review in comment mode. He has a great idea about including manifest files (more later). IF you are ever keen and the post is still up, check it out for a look at open collaboration about methods.
    • OUR copy of doc with comments open the comments thread...feel free to comment on this one for our internal use
  • ideas for GAS series working sessions
    • use the "Gist query my sheet" demo to build a 2d array from sheet data
      -[ ] try out a few patterns on this data
    • PhaseII? - grab real problems posed in G+ for discussion; for example, this one has a recommended solution where the answer involves a simple and an installable trigger. Triggers might be a topic
      • setup a series to solve, then work the list practicing working in GAS
    • Incorporate manifests so required services are more clear and GAS GitHub assistant pulls them as well. This is a js file you can make visible in the web GAS editor. Review also Other DevFlows from GDEs in GAS Basics Part 1 notes as it was their suggestion

• Next Week: part 2

2018.06.27 WS-GAS Basics Part 2

Recording Link

Agenda with notes

• GAS Basics working sessions to try out GAS on sheets data; some of these could be turned into demos of successful "GAS patterns"
  • UPDATED approach, use the new repo to get the code and add it to a fresh sheet.
• Topics covered include
  • Review great links
  • Create a new repo for this "BurningGAS"
    • Pull in last weeks two functions and onOpen menu in a new repo
    • modify to create the input sheets
  • Gist query my sheet build
• This week's Cool links:
  • our new repo for these GAS sessions
  • Check the learning GIST for these two new links; we will likely pull the GIST into our new repo
    • This great gist by Amit Agarwal
    • For tutorials covering the basics, check out The website of Barrie Roberts
  • explore these sources for data to use, especially 5
  • Looking for data? Try Kaggle
    • Datasets
    • KAGGLE example 'google job skills'
  • Javascript Linter Online tool
  • atom plug in options
    • Javascript Linter in Atom
    • Javascript Linter in Atom
  • next week's topic
• Next Week: part 3

2018.07.04 WS-GAS Basics Part 3

Canceled due to holiday; merging with General Session II.

2018.07.11 GS-General Session II (and WS-GAS Basics Part 3)

Recording Link

Agenda with notes

• GAS Basics working sessions to try out GAS on sheets data; some of these could be turned into demos of successful "GAS patterns"

• Topics covered include

  • Catch up on the gas workshops via the video links and
    • our new repo for these GAS sessions "BurningGas"
  • Demo 'Gist query my sheet' shows SQL like query to a 2d array and use of advanced sheet service to right-size the new sheet with the exact number of rows and columns required
  • demonstrate GitHub /compare feature
    • 1.1.0 Gist query my sheet "make it possible"
    • 1.1.1 Faster - batching more actions for speed "make it faster"
    • 1.1.2 Functional - slightly slower for a reason, leveraging API best practices and workarounds "make it pleasant" for the first run, re-run

• This week's Cool links with a few more added for time off:

  • the importance of speed Incredible information here.
  • Designer vs. Developer YouTube series - Designer vs. Developer aims to provide takeaways, solutions to workflows, tools & discussions on everyday struggles. Especially check out the notes for links. For example, #17 "Using Gestalt Principles to Improve Your Design" mentions these two gems among others
    • Gestalt laws of grouping
    • Universal Principles of Design
      • Becoming Leonardo: How Great Designers Think on youtube free
  • revered article on javascript patterns with modules
  • replay of Google's App Maker panel session Totally Unscripted panel on App Maker Questions
  • dotfiles Your unofficial guide to dotfiles on GitHub. Let's discuss if we need to define this as part of our setup and config or an open call for tools that do this
  • A deep set of highly competent content for GAS skills This person's work is amazing. Go deeper with the links and learn lots.
  • Google Apps Developer Series: How to Increase Traffic to your Add-On With AppsScript Inventor of GAS gives addon advice, originally a Cloud Connect Live Event Streamed live on Jun 2, 2015. Great material. Also, they mention which javascript engine is being used!
  • Using Google Apps Script to automate G Suite (Google Cloud Next '17) This more recent walkthrough has a very good and straightforward set of code examples in their presentation. Especially look for stubbing of services for testing in the Gmail example and the use of templated HTML with regard to the use of escaped javascript in the html file in the web app section - not sure if the second one is best practice or not but it's interesting.

• Next Week: IMPORTANT TIME OFF MESSAGE

  • Taking time off to catch up with coursework. General Session 3 Canceled!
  • No working sessions until 2018 Aug 22
  • General Session 4 on Sep 12th will demo our version of the addon and will be a good one to attend as we will be ready to share demo credit if you can take one after seeing how we lay them out
  • Demos for phase II will be assigned by the end of working session Sep 19th...."claim your demo or lose it for phase II :)"

2018.07.18 WS-Canceled

2018.07.25 WS-Canceled

2018.08.01 WS-Canceled

2018.08.08 WS-Canceled

2018.08.15 GS-Canceled General Session III

2018.08.22 WS-Resume Weekly Wednesday Working Sessions

Recording Link TODO

Agenda with notes

• our add-on working sessions to prep our addon so volunteers can add demos

• Topics covered include

  • Setup 14-day sprint on ZenHub
    • prep ZenHub SPRINT 1 - Aug 22 - Sep 5
    • skeleton only, we will add detail as possible
  • Start work
  • GitKraken has many great updates, so make sure you have latest. Like syntax highlighting and a code editor inside the interface https://www.gitkraken.com/git-client#code-editor

• This week's Cool links:

  • Automating G Suite: Apps Script & Sheets Macro Recorder (Cloud Next '18) - Nice overview
  • Excellent summary of changes from Next - also has links for training like on clasp
  • Community talk about clasp - discussions on getting clasp ready for our use, but we are held up with the issue of renaming .gs into .js which doesn't work for us just yet
  • Clasp - start this open source repo so you can keep track of it
  • Good article, from a straight shooter - check out her blog and work as well

• Upcomming:

  • Shakeout our first sprint from Aug 22 - Sept 5, 2018
  • General Session 4 on Sep 12th will demo our version of the addon and will be a good one to attend as we will be ready to share demo credit if you can take one after seing how we lay them out
  • Demos for phase II will be assigned by the end of working session Sep 19th...."claim your demo or lose it for phase II :)"

2018.08.29 WS-Addon Standup

Recording Link

Agenda with notes

• our add-on working sessions to prep our addon so volunteers can add demos.

  • Shakeout our first sprint from Aug 22 - Sept 5, 2018

• Topics covered include

  • Continue ZenHub sprint, update issues
  • Permissions on repo and adding a collaborator
  • use Placeholder.com to create our marketing tiles for the welcome, and example first demo
  • per G guidelines we need the following for our store listing (even if publishind to group or domain)
    • Small tile - 440x280
    • Large tile - 920x680
    • Marquee - 1400x560
  • We will need to resolve how we want to handle the small addon icon with a 96x96 internal symbol (see google guidelines) Guidelines for square icon: 96x96pixels for the art inside and 128x128 pixels overall
  • We will submit files for the 'market listing' top level, but for each demo you can use these for now by reference.
    • https://via.placeholder.com/440x280?text=SmallTile
    • https://via.placeholder.com/920x680?text=LargeTile
    • https://via.placeholder.com/1400x560?text=Marquee

• This week's Cool links with a few more added for time off:

  • next week will share again the UI guidelines and the market listing instructions
  • for example see icon section

• Upcomming:

  • General Session 4 on Sep 12th will demo our version of the addon and will be a good one to attend as we will be ready to share demo credit if you can take one after seing how we lay them out
  • Demos for phase II will be assigned by the end of working session Sep 19th...."claim your demo or lose it for phase II :)"

2018.09.05 WS-Addon Standup

No recording. Working session.
Hot links include incorporating Clasp see #62.

2018.09.12 GS-Demo state of Addon Standup, highlight sprint lessons learned, demo ideas

RECORDING
PRESENTATION

Agenda

• install of the unlisted add-on
• two demos
• full demonstration of what the workflow looks like from feedback to publishing a change
• a code walkthrough of how the add-on works

If you want to do a demo, let us know by saying so on issue 46 by Wed the 19th. State which one and whether you'd like to get it done before next General Session on second Wednesday in Oct or during phase III and we will reserve it for you. Two easy and a third possible, others will be in Phase III. Watch the vid, pick one if you want. Contributors get their pic and LinkedIn included as part of the demo AND can say they contributed to an open source project.

• Update multiple cells (from BurningGAS example)
• Manipulate disjoint ranges (from BurningGAS example)
• What's new (from Totally Unscripted, if the creator doesn't want to do it)
  Working sessions by appointment, otherwise next session will be Oct 11, 2018, to close Phase II

2018.09.19 DEADLINE to Claim or lose a demo for phase II

2018.09.26 no session

2018.10.03 no session

2018.12.12 GS-General Session: Phase II Lessons Learned

Agenda:

• State of the repo and release updates
• State of the repo and release updates
• Lessons Learned and Feedback summary
• Phase III plans
• What to do next

Notes:
1 Here's the presentation PDF with live links AND the recorded session of 41m 30s.
2 Be sure and also check the pdf slides as we added a little content after the meeting.
3 Phase III is OPEN TO THE PUBLIC (more to come)
4 Feedback themes

• Themes - focus/audience, amount of content, complexity of content, there is a value to create and deliver
• We made Alexander Ivanov’s google apps script awesome list
• we are #3 in a current google search!
• Feedback from G+ Moderators

5 Rudy's notes on organizing principles of getting good at something B/H, C, M
B/H - behavior the critical success factors
figure out what they are, make them your habits, observe the best you can find, follow critical content creators on twitter, pay attention

C - competence
many kinds/domains (this is the stuff of methodologies) examples of competence/acumen include - technical, professional, business, others…
in your career you will generally be working on maybe 4-8 that you should master (check that number, i’m just throwing that out there)
rating competence - if on a scale of 1-5; 1 would be newly trained and 5 might be gets paid to present or published content for sale

M-mastery
10,000hrs + continual learning
a good motto borrowed from martial arts “we need more practice”

6 Closing notes
Rob and I will be working on DevFlow as an ongoing open source with attribution project. So keep watching the space. Also, you can now watch for release updates.

Startup activities:
Additionally, I applied for the ND to learn how to make my own prototypes and help me in bootstrapping a startup.
If you want to learn about that, get to know us through the DevFlow project first.
If your company is looking to establish a GAS team using DevFlow, please reach out as I might be doing some of that in the new year as well.
7 Next items

• Star and watch releases of DevFlow, BurnginGAS, and any issues/epics you like
• Install the private link to our google sheets add-on; play with it with overtime when there are new releases
• Exlpore the resource link hosted on diigo
  SEE YOU IN 2019!!!!!!!

Have a question or comment?

Add it to this issue history in a new comment block and mention TODO or TODO. Thanks.

Standup repo as testable add-on for collaboration

objective / purpose
Establish repo, shake out process with 1 test account and volunteer, get addon to point of being able to clone and run test as addon.

Functional requirements for this epic

Criteria	Meets Specifications
1. Comply with rubric	a. no rubric
2. Promo Tiles	a. TODO: update notes see also #49
3. Comply with authorization lifecycle	a. Install and onOpen trigger functions that create menu scheme for all demos and allows for start/restart
4. DevFlow Guidelines	a. Follow addon conventions b. Use semVersioning w 'make test ready' automation and nested namespacing see #8, #5, #11, #13, #14 c. Templates and guidelines for git commits, glo board usage. see epic #34 ,
5. Demo participants	a. Enable demo so phase II participants can add their demos following our guidelines.

Demo CSS Package for Add-ons

objective / purpose
Demo to walk through examples of the CSS pakage for add-ons. consider including link to style guide.
Create an issue for each part.

Working notes

see also https://developers.google.com/apps-script/add-ons/css
and https://developers.google.com/apps-script/add-ons/style

Solution Design

restart is showing old menus compared to start workflow

objective / purpose
restart not creating new menus like start workflow is
completion checklist

• Discovered in: v0.5.0
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Current work around:

• refresh sheet
• start workflow
• use that menu

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Make test ready edge case Naming your script 'Unexpected goListStatus in renaming. Investigate.'

objective / purpose
see #56
completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Bad link to label copy tool in contributing.md

objective / purpose
fix bad link. (see images)
completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Demonstrate "What's New"

objective / purpose
"what's new" - the what's new approach from earlier TU Episode

completion checklist

• Discovered in: whichx.y.z or n/a
• Resolved/introduced in: whichx.y.z
• Design Ready - labels, estimates
• Development Ready - design and change list created, updated complexity label and estimates
• Changes Listed (mark each member as completed update as needed)
  • one
  • two
  • three
  • four
  • five
• Developer Tested - Test Copies (Disposable Alpha "DA!s" and Release Candidate)

POST LIVE:

• Beta Tested - Live to controlled audience  
• Customer Experience - Live analytics reveal working for customers  

full pipeline documentation

Overview - describe with history and related items

Solution Design

What's New Entry

Solution Implementation Notes

Developer Testing- Disposable Alpha and Release Candidate

Live Testing - Beta live to controlled audience

Customer Experience - Re-open and append if issues for customers

Answer Wednesday Spectator Questions

Establish best practices (DevFlow w Special Projects Admin)

objective / purpose
Shake out how we work special projects with volunteers and on team. This epic will collect meta type work so we can establish best practices we will later bake into what we call DevFlow.

Functional requirements for this epic

Criteria	Meets Specifications
1. this	a. subtopic b. another sub topic
2. that	a. subtopic b. another sub topic
3. this	a. subtopic b. another sub topic
4. that	a. subtopic b. another sub topic
5. this	a. subtopic b. another sub topic

How do we update our avatar profile picture?

How best to update profile image in avatar

In DevFlow, we have github accounts, gitkraken accounts and others. How can I best manage my profile image?

GitKraken

Will use a few of theirs and sometimes your github avatar. BUT it will use a gravator if you have one with wordpress by checking for one with the email you use for GitKraken and GitFlow (the same).

GitHub

GitHub uses identicons and allows you to set a profile image. Intructions here

Final Answer

See this wiki how and gravatar site to setup a gravatar for all your needs :)
Create a gravatar associated with the same email you are using for GitKraken and then it will just work.

• update url for wikihow and gravatar
• update github notes and see if they can use gravatar as well so consistent