Closed SmokyBob closed 8 years ago
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.
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 https://github.com/GoogleDeveloperExperts/gde-app-backend/issues/3#issuecomment-115368545 .
K understood about 1, edited
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
(Changes) to existing tags
Activity Type Tags Let's consolidate the current activity tags to fall under the following larger 4 categories:
Content: #blogpost,#video,#article,#tutorial,#forumpost,
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)
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:
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.
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
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
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
Have a look and let me know what you guys think.
https://10-dot-gdetracking.appspot.com/#/
Pushed some code to my fork which can be seen here
https://github.com/patt0/gde-app-backend/commit/12608c43f5ee839d60823fb95ab9b52b8d7a4d14
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
Sounds good to me :+1:
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.
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.
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
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 https://github.com/GoogleDeveloperExperts/experts-app-backend/issues/3#issuecomment-120907533 .
Ok so an example post tagging could be
or
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
Sorry for writing only now, busy interviewing another possible Polymer Expert.
Just to keep track with what Nat said:
Was starting to work on #13 but remembered that the update_gplus.py service checked the account.type
to be active
(here).
We have to possibilities:
category
field to the account
object, and leave the type as istype
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?
... 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...
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 https://github.com/patt0/gde-app-backend/commit/53212d225dc6a1ab07bfe9f206472477ec64db0c
@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.
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:
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)
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 https://github.com/GoogleDeveloperExperts/experts-app-backend/issues/3#issuecomment-121612524 .
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.
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:
Changes to the current data structure are needed to support the features listed above.