Onboarding Experts from other area of expertise

[SmokyBob]

This is more of a way to keep track of the TODO than a proper issue, more detailed Analysis/discussion can be done "privately" with Docs and more detailed issues and TODOs will be added to the repo in the future

Currently the app is tailored to fit the "tracking needs" of Technology Google Experts.

The need to track activities is for other area of expertise too so why reinvent the wheel? :)

Some points of discussion about tracking activities for other areas of expertise are the following:

1. Do they need a Google + ID or we want to support other Auth methods? <- Yes, needed for the Cloud endpoints
2. New Activity Types (with associated tags) for each area of expertise and new Activity groups needs to be defined.
3. Are there "Products" for other area of expertise?

Changes to the current data structure are needed to support the features listed above.

[Scarygami]

About 1: They do need to have a Google account or authentication with Google Cloud endpoints doesn't work to submit/edit data in the tracking app, it doesn't need to be a Google+ account, but Google account and Google+ account share an ID anyway.

[patt0]

That is my view
On 26 Jun 2015 00:49, "Gerwin Sturm" notifications@github.com wrote:

@1 https://github.com/1: They do need to have a Google account or
authentication with Google Cloud endpoints doesn't work to submit/edit data
in the tracking app, it doesn't need to be a Google+ account, but Google
account and Google+ account share an ID anyway.

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[SmokyBob]

K understood about 1, edited

[patt0]

We need to refactor the backend to manage the following new tags, categories and activities

Tracking
All Experts should track using the general Experts tag (#experts), their Category, Product, and Activity. example: #experts #marketing #branding #book Tags for Experts (general)
Program: #experts
Categories: : #gde/ #marketing/ #ProductStrategy/ #UX/UI
Product:
Marketing: #branding #monetization #distribution #DataAnalysis
Product Strategy: #ProductStrategy
UX/UI: #uxdesign #MaterialDesign

(NEW) Additional product tags for gde
#brillo
#GCMiOS
#GCMtopics
#diagnostics (connected with #Android)
#appindexing (connected with #Android)
#deeplinking (connected with #Android)
#AndroidM
#analytics

(Changes) to existing tags
#gdeprogram: needs to be changed to #expertsprogram

Activity Type Tags
Let's consolidate the current activity tags to fall under the following larger 4 categories:

Content: #blogpost,#video,#article,#tutorial,#forumpost,
#techdocs,#book,#translation,#opensourcecode
Speaking: #techtalk
Testing: #bugreport
Pack Leader: #interview, #community
Mentoring: for mentoring activities and design sprints, they don't need to be reported. We receive and track those activities when Experts register for the event with the Regional Leads or through the global program. (we will update you if this will change in the future)

[SmokyBob]

Making products available by category should be simple (just by adding a category property on the Product; ex. #android = gde, #branding = marketing), we'll still need a separate entity to include descriptions.

My doubt is how we want to manage the "connected with" tags:

1. enforce the "connect with", ex. if I forget the #android tag the activity is not picked up/ we mark it as incomplete
2. just the "child" tag is enough, ex. #diagnostics alone will mark the activity as #android and #diagnostics
3. Aggregate or keep them separated, (mostly on the reporting side of things, asked in the original doc); Ex. if I look at an #android chart/repo, should #diagnostics activities be included or not? should I be able to see a #diagnostics only chart/repo?

[SmokyBob]

Answers from Natalie:
A. #UX/UI -> #ux_ui is cool
B. "connected with" -> Just the "child" tag is enough, the activities will be aggregated as Android in the reports, it's stated clearly in the description that those tags are #android activities only

I'll open an issue for B on the front End to keep track of the request to aggregate the tags for reporting only... maybe will need a displayAs tag on the PG object to handles this cases in a configurable manner.

[Scarygami]

So we would have a structure like this:

Category	Product	Area
#gde	#android	#diagnostics
		#appindexing
		#deeplinking
	#AndroidM
	...
#marketing	#branding
	#monetization
	#distribution
	#DataAnalysis
#ProductStrategy	#ProductStrategy
#ux_ui	#uxdesign
	#MaterialDesign

From the reporting side, wouldn't it make sense to offer the user the possibility to view reports on whatever of those levels they want to see. a big overview on "Category" level. a general product specific report, or going down in all detail into product areas?

To achieve this it might be useful to create the "Product group" entities like this:

Category	Product	Area
#gde	#android	#android
#gde	#android	#diagnostics
#gde	#android	#appindexing
#gde	#android	#deeplinking
#gde	#AndroidM	#AndroidM
#gde	#chrome	#chrome
#gde	#chrome	#polymer
#marketing	#branding	#branding
#marketing	#monetization	#monetization
#marketing	#distribution	#distribution
...	...	...

That way, defining the "area" in a post would be enough to uniquely assign it to a product and a category, e.g. just with the tags #experts #branding the rest would be clear.

One thing we have to be careful about (need to discuss this with Natalie/Ola) is that we don't run into the same "problem" with using #experts as we were with using #gde. But we might want to rethink our tracking approach for this and only pick-up posts that have a minimum requirement of #experts + category/product/area-tag

[SmokyBob]

I think picking up posts with #experts + category + area can be safely the new minimum... if I'm making a post with #gde #experts #polymer ... even if I'm not making an activity... I probably should

[patt0]

As i work through this I am adding a couple of properties to the
ProductGroup entity for
'category' and 'product' while the tag represent #area.

We need to ensure that #area is unique across the PG's

I also pushed all the tags from the PG AT AG sheet

I have uploaded a test implementation on firefly which can be observed here
and am running some test and I think we can just harvest with the main tag
#experts / #gde (temp) and the area hash tag to pick up post.

Have a look and let me know what you guys think.

https://apis-explorer.appspot.com/apis-explorer/?base=https://4-dot-elite-firefly-737.appspot.com/_ah/api#p/expertstracking/v1.0b2/expertstracking.product_group.list

https://10-dot-gdetracking.appspot.com/#/

Pushed some code to my fork which can be seen here

patt0@12608c4

[patt0]

I have run a complete update cycle for all the tasks, everything seems to be working, I am inclined to push the new tags and the harvesting code to the existing API so we can tell Ola and gang that they can start pushing new users to us and they can start using the app, reporting their activities. What you say @Scarygami @SmokyBob

[Scarygami]

Sounds good to me 👍

[SmokyBob]

Sorry for the late response.
The PR will match any PG as long as the post have #experts or #gde?

I think the PG should be considered correct, only if the PG.category matches the expert.Category
For now we can assume is always #gde because we have only this category of accounts.

Going to open an issue about updatint the Experts Masterlist to create accounts with other categories and validate the configured PGs by Category.

[Scarygami]

But wouldn't that limit the activities of e.g. Android GDEs who already now post amazing stuff about (material) design/ux without being a UX/Design-Expert by name? Those activities would (in my opinion) be interesting for the UX-reports as well. This is basically the same discussion we had in the beginning with GDEs having activities in other than their "assigned" PG, where the decision then was to track all activities across PGs.

[SmokyBob]

I see tour point but in my understanding the category on pgs is to filter and see how many activities each expert group have... But I might be mistaken.. I'll ask as soon as I've finished lunch

[patt0]

I also think we should not exclude post that are across pg's rather we can
filter at the report level, and if a few experts cross pollinate, all the
better.

Patrick Martinent

On 13 July 2015 at 17:47, Mauro Solcia notifications@github.com wrote:

I see tour point but in my understanding the category on pgs is to filter
and see how many activities each expert group have... But I might be
mistaken.. I'll ask as soon as I've finished lunch

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[SmokyBob]

Ok so an example post tagging could be
#gde #experts #monetization #android #admob
or
#marketing #experts #monetization #android #admob

and they'll both count in 2 categories and 3 PGs?

Mail to Nat coming in seconds with the same example

P.S. Sorry for being telegraphic

[SmokyBob]

Sorry for writing only now, busy interviewing another possible Polymer Expert.

Just to keep track with what Nat said:

• Activities PGs: track only the one from the same category as the Expert's
• Activities are tracked as long as they have #experts, category tag is not required (#gde, #marketing, etc..)

Was starting to work on #13 but remembered that the update_gplus.py service checked the account.typeto be active (here).
We have to possibilities:

1. add a category field to the account object, and leave the type as is
2. use the type field to store the category and change the update job and other places where type is checked, and check it against 'deleted'

What are your thoughts on this?

[SmokyBob]

... or we could infer the Category on the Expert from the first of its PGs, trusting we don't change the Category on the PGs...

[patt0]

I am happy to make it as simple as possible for you, its just a couple of line here and there in the update service checking for the account type.

For now I am going to accept active and all the category types, then when you give me an ok, I can remove the active type from the accept list.

I can't seem to see any 'admin' or 'administrator' type anymore.

If we are happy with ...

'gde'
'marketing'
'productstrategy'
'ux_ui'

Then I have pushed the following commit to the backend patt0@53212d2

[SmokyBob]

@patt0 Looks good to me.

I'll clean up the MasterList and WebApp code to us the account.type instead of infer the category from the account's PGs.

[SmokyBob]

Today's updated on the tags after the discussing with Nat & Ola some issued on the creation of ux_ui Experts.

for UX please use the following # instead:
#UserResearch
#InteractionDesign
#VisualDesign
#MaterialDesign (which is kind of like App Indexing on Android)

I'll update the tags in the PG AT AG Masterlist and do all the pushes to the backend as soon as I get out of the office (or let me know if you do it before 7 PM CEST)

[patt0]

DONE

does this mean we remove the #uxdesign ?

Patrick Martinent

On 15 July 2015 at 18:49, Mauro Solcia notifications@github.com wrote:

Today's updated on the tags after the discussing with Nat & Ola some
issued on the creation of ux_ui Experts.

for UX please use the following # instead:
#UserResearch
#InteractionDesign
#VisualDesign
#MaterialDesign (which is kind of like App Indexing on Android)

I'll update the tags in the PG AT AG Masterlist and do all the pushes to
the backend as soon as I get out of the office (or let me know if you do it
before 7 PM CEST)

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[SmokyBob]

Thx.

Yes uxdesign would have been the combination of InteractionDesign and VisualDesign but the "fear" is that if it was available everything was tracked under it.
these changed provide a more consistent mapping with the Area of expertise for ux_ui experts too.