Proposal: Blockstack PBC employees can provide feedback/advice, but not code or design

[stackatron]

As far as I am aware, there have never been any problems on this topic yet, but trying to prevent problems before they could potentially begin. The proposed guideline:

Blockstack PBC employees are free to review apps, give feedback, and suggest improvements to any app, but will avoid direct help in the form of code or design.

[markmhendrickson]

I think it's generally a good idea to create clear rules that prevent favoritism towards specific App Mining participants, but we may need to be very specific about those rules and design them to prevent favoritism of specific apps while not tying our hands from systematically helping developers in personalized ways.

This feels like a tight line to walk since we're eager to help out all apps wherever and whenever they most need it. And lots of that help could be given in a lumpy, non-uniform way across participants even when favoritism is not intended in the least (but rather, specific developers simply ask us for help more or we become aware of their needs sporadically).

Some questions around clarity:

• Would submitting a PR request to an open source repo that upgrades their blockstack.js version count as a code violation?
• Would outlining a bunch of detailed, in-depth UX suggestions in a document count as providing design if it's not visual (or is being visual the determining factor)?
• Would having (recurring) meetings with startups to provide them wide-ranging counsel (e.g. financing, hiring, or Blockstack infrastructure) violate the spirit of avoiding favoritism despite lacking code or design contributions?
• Would treating specific developers' needs as templates for functional improvements to the Blockstack platform constitute favoritism, especially when they have advance awareness of those improvements as the result of research and planning conversations?

We're never going to achieve complete "help" parity across participants, if we help at all. And I don't think we want to take a "no help in general" approach, since that'd be so detrimental to our community's progress.

So perhaps we need to set the expectation that we'll forbid the most egregious and obvious forms of favoritism, but that no one should expect we may won't effectively give certain participants more help than others?

We may want to also be very clear about the ways in which developers can ask for our help, so at least we're making ourselves as fully available as possible to all participants.

[stackatron]

Yep, I agree with all of that and the terms I suggested are my attempt to establish some guardrails. As for your examples:

• Specific PR to upgrade = fine.
• List of UX suggestions = fine.
• Recurring meetings = fine.
• Needs as a template = fine, since we also prioritize upgrades based on all App Miners needs.

Rather than defining all cases, I was hoping to just define a couple key things we'll try to avoid in the spirit of no favoritism: No code, no design.

[cuevasm]

How would this impact something like coverage and content? My suggestion is that as long as the same opportunities to post, interview, etc are available to everyone its all good, worried about how I could possibly make Twitter fair in supporting apps though. Distribution wise I couldn't guarantee the same number of posts for one projectn with another, it's dependent on content and what's timely.

[friedger]

How about adopting the use of an app? Should Blockstack PBC be allowed to use apps, host their own copy of the code etc.?

[stackatron]

sounds like @cuevasm has some ideas for next steps on this.

[stackatron]

Seems like we don't have a real problem here yet and we have a ton questions, why don't we just close this for now and we can readdress if something comes up.