2018-11-28 Engineering Meeting


#1

Date/Time: 2018-11-28 @ 15:00 UTC / 10:00 EDT / 23:00 HKT
Click here to convert to your time zone
Length: 45 minutes
Meeting link: [https://zoom.us/j/966890423]

This meeting is for the engineering team, app developers and the community to discuss engineering concerns or questions.

Agenda

Please reply to this forum post with items you would like included on the agenda.

Each item should include:

Item name
Background information: Links to github issues, forum posts, etc with background information on the item
Desired outcome: what decision or deliverable would you like from the discussion of this topic at the meeting?

Meeting Minutes/Notes (please review/correct as needed)

2018-11-28 Meeting Notes

Open Source Metrics

Open Source engagement Metrics generally are response rates to external
community members. And close rates on issues and PRs. This is the last month
over our repositories.

Only two issues closed and

  • Metrics are in the engineering meeting.
  • He has a script and he can provide us with the script. There are some tools from Open Source companies. Gremlin (Chaos) has a tool Gremwar lab.
  • Discussion of hosting this service so outside folks can see the .
  • Aaron will post on the forum the different tools.
  • Move people out of Slack and out of the Forum.
  • Muneeb: Always be directing the discussion to the GitHub to keep the community focussed there.
  • If a discussion in Slack is more than a one word focus.
  • Jude would like to see further depth in the metrics so he can be a better maintainer.
  • Muneeb: I think this is a good check for how engaged our community is. If you are truly operating as an open source project, you do these things online in an open meeting. Posting the meetings. Asking favors can result in more involvement.
  • Jeff: Sometimes it is good to ask people to build things or do things.
  • Virgina: We need to be aware that App Mining.
  • Jude: Do we tell people that sign up for App Mining get information about this meeting? No was the answer.
  • We should maybe attend other open source meetings to find out how they are run.

ACTION ITEM:

  • Mary creates a how to use this Forum/Slack/GitHub post and pins it.

Scoped Gaia Auth Tokens Discussion

These would allow admin of an organization give a token that allows users to
write to a specific path. This would allow you to easily manage collaborative.
Reduces management by the app of coordinating among individual repos. This is a
scoped Gaia API key.

Aaron: Agrees with use case 1 not the second. For the second, he sees that a user who
controls a single Gaia hub could use the whitelist feature to get this than a
scoped.

Hank: Discusses the Graphite case…and he sees that it is possible that whitelist is possible solution yes.

Larry: This is hitting to an API/end point we haven’t documented in the past.
There is no doc or discussion around this API — it has been a private thing.
ConnectToGaiHub is private…we should leave it that way until we have a cleaner
API implementation. Also we need to have a way to revoke these.

Larry/Hank: Both want to talk about this further.

Aaron: We need to think through how we want people to work through GAIA if they aren’t just doing gets/puts.

Larry: It isn’t clear how this fits into the “when” should you do this.

Aaron: The API we present needs to show how to use it. Also, the concept of
scoped auth tokens as it exists now is problematic because they can’t be
revoked. We should address these separately.

Larry: Thinks these issues belong in the same discussion, not separate.

Virgina: Maybe we should encourage people to give them out if we can’t revoke
them. Same vein, users can’t delete their account. Gaia needs to allow users to
view and delete their own data. We need to think about this in general. We are creating some residual issues.

Ken: Has concern about these scoped tokens. Between the Gaia and account data — what are t…

Jude: There is a case where users don’t have Gaia storage. For enterprise case
not all employees will have a GAIA hub. In enterprise, you want a company or
dept hub.

Aaron: EAch of these employees would have a different keys. Why would you use scoped tokens there?

Jude: It is more a dev env management problem. YOu want your employees to all
have something the company controls.

Aaron: The server is the central…the hub is on a company machine. Each
employees bucket is on that company server. There are a variety of use cases
with a token.

Jude: I may not have communicated the case well enough. MIsos and Graphite –
they are trying to integrate with third party external services. Your service
can use their bucket but the company won’t have the data. Or you can have
solutions that allow the service to integrate with the company’s hub.

Aaron: This is a valid use case. Scoped tokens in the regular interent is
basically for creating robot XXX. The association token it makes it so you can
whitelist one address on a Gaia hub. This allows only these addresses to write
to the Hub. Each hub manages multiple buckets. To write to a bucket you need
the key. EAch application writes to a specific bucket. The whitelist says only
the following keys can write at all. Thsi limits the number of buckets. As a
user, you don’t want to write each app address to the whitelist. So, what he
does is allow users to associate apps with a single key on the white lists(sic).
Assocation keys are meant to be used in an authenticator app — programmatically.

Jude: Brings up OKR 5.4 and …

Aaron: My understanding was that OKR was limited in scope.

Jude: If we are modifying the browser already…this maybe only one or two lines to do. We only need to do a quick PR

Jude/Aaron: Already discussing this

Virgina: Do we need to clarify the intended use case.
Aaron: Yes. Some of these tokens are not intended to use it all.
Mary:We should mark things people shouldn’t be using as private so people know if they use them they are at risk, we can deprecate or change.

Virgina: We will take a stab at.

Aaron: The takeaway is we should continue to have this feature marked private. We should decide if we need to have this feature at all.

LarrY; We probably want to expand this meeting it there is more than two topics of signifigance.

There are two topics.

  1. Revocation.
  2. …

The other issues are linked and there was a discussion on the PR. There needs
to make a more product led approach to our API. We need to make sure we have
discussion.

Virgina: Even in our GAIA meeting there is just 6-7 new meetings.

Mary: Maybe we need to have Roadmap for our projects? That way we at least know the direction.

Virgina; Issues keep coming up in meetings. If we had a Roadmap if we had that might keep it from getting to feature happy.

Ken: I think we also need a Roadmap for Blockstack Js and SDKs.

Larry: Ken you are going to be taking the lead on that from Muneeb.

Ken: Yes, that is correct.


#2

Open Source Metrics

Background: I’ve started collecting some metrics that are the sort of standard metrics for community engagement – basically it’s response time on issues and PRs from community members, and then open/close rates on community issues and PRs. This data is measured over issues and PRs created in the last month. It says nothing about stale issues in our repos, which we can measure separately, and should deal with.

Desired Outcome: Complain about this report if it looks fishy to you! Also – looking into the details of it, it seems like the animal-kingdom repo is likely to get a lot of issue traffic. Do we want to engage with those issues from users?

Summary Data:

issues PRs
open closed no response days to close days to response open closed no response days to close days to response
All creators 41 8 27 2.4 0.5 14 47 25 0.1 0.3
External only 7 2 4 NaN 16.1 3 5 0 1 0.1

So, looking at just external issue submissions, there were 9 new issues over the last month, 7 still open, 4 not-responded to, and 2 closed.

We do a much better job right now, it seems, responding to PRs quickly.


#3

Animal Kingdom hopefully will get more issues! There is a step in the tutorial where I ask them to create an issue asking us to add their kingdom to our by creating an issue.

So, I will get them. And close them with PRS.

I would like it if we stop pointing people to @larry’s instance. Just because Blockstack should be the official one. Sorry, Larry, I will add about the creator at the bottom of our readme.


#4

Scoped Gaia Auth Tokens

Background: There’s a pull request that adds support for scoped gaia auth tokens to blockstack.js. These enable the ability to give a third party write access to one file or a portion of an app’s storage bucket. See the discussion at https://github.com/blockstack/blockstack.js/pull/545#pullrequestreview-178046186

Desired Outcome: I’d like to better understand use cases and decide the best way to integrate support for this into blockstack.js


#5

Wouldn’t it be easier on everyone if someone just submits a PR, rather than an issue which we then PR ourselves? It would reduce the amount of issues in the repo.


#6

Issue tracking:

GrimoireLabs:

OSSTracker:


#7

The last time I tested osstracker, it was a pretty big and complicated install.
Either of these will be a pretty involved setup according to the docs - there are a lot of moving parts involved.


#8

Yeah, that’s exactly why I ended up caving and writing a script.

Here’s the repo breakdown:

issues PRs
open closed no response days to close days to response open closed no response days to close days to response
blockstack.js 5 0 1 0 9.9 0 3 0 13 1.9
External only 2 0 0 0 NaN 0 0 0 0 0
blockstack-core 2 2 2 NaN NaN 2 7 1 0 0
External only 0 2 0 NaN NaN 0 1 0 NaN NaN
gaia 3 0 1 0 NaN 0 3 0 5 0.8
External only 0 0 0 0 0 0 0 0 0 0
blockstack.org 3 1 3 NaN NaN 0 11 8 0.1 0
External only 1 0 1 0 0 0 1 0 NaN NaN
blockstack-browser 8 0 7 0 NaN 2 0 0 0 NaN
External only 1 0 1 0 0 1 0 0 0 NaN
blockstack-explorer 1 0 0 0 NaN 0 0 0 0 0
External only 0 0 0 0 0 0 0 0 0 0
blockstack-app-gener 1 0 1 0 0 4 0 1 0 19.1
External only 0 0 0 0 0 2 0 0 0 NaN
blockstack-ios 3 0 2 0 NaN 0 0 0 0 0
External only 2 0 1 0 NaN 0 0 0 0 0
blockstack-android 2 0 1 0 NaN 4 1 3 NaN NaN
External only 0 0 0 0 0 0 0 0 0 0
app.co 5 3 1 7.9 0.6 0 1 0 NaN NaN
External only 0 0 0 0 0 0 0 0 0 0
docs.blockstack 2 0 1 0 NaN 1 14 11 0 0.7
External only 0 0 0 0 0 0 3 0 1.1 0.5
cli-blockstack 5 1 5 NaN NaN 0 2 0 NaN NaN
External only 0 0 0 0 0 0 0 0 0 0
animal-kingdom 1 1 2 NaN 0 0 1 1 NaN 0
External only 1 0 1 0 0 0 0 0 0 0

#9

Yes, that would be easier for us. Not everyone is a great coder. GitHub alone confuses people let alone PRs. And GitHub’s “easy file edit” often results in really crappy PRs that you can’t iterate over. Issues are easier.

Erhm, I expect the smart people like you @jwiley to actually do a PR. I’m waiting to see who those people are.