-
Notifications
You must be signed in to change notification settings - Fork 16
Proposal: Stop Using Github to Communicate Important Information #110
Comments
Sending an email whenever Changelog.md was updated sounds a good solution! |
To help app publishers please use labels: #97 |
I think it is the right time to add " App Miner portal" ... the place where every app miner can check the monthly results.
|
@friedger and @jehunter5811 I fear that may be a lot of emailing if it is simply for every discussion finalized in the changelog and a good compromise might be to simply clarify the scoring method via email at the start of every month. What are your thoughts on this? @dmailonline we're absolutely looking to do this, however it is a longer term project for our team and something we need to dedicate more resources to in the future to accomplish. You can track that here: stacks-archive/app.co#420 |
I think that's a good start, Gina. I just don't know that that will fix problems like discovering that a critical piece of information (Awario results) was buried in github comments. To be clear, I'm not proposing email fro discussion. In fact, I suggest we continue to use Github for that. But every month, I think an email that includes the following would be just fine. Here are the rules for next month |
Agreed on Awario, and is being addressed in #108. Thanks for the suggestions, I think emailing with most of this info makes a lot of sense moving forward. Not sure how much we can share in tips on a monthly basis, but good to take into consideration. |
I meant monthly emails as well.
There are tips in docs.blockstack.org. Maybe just pick one each month to
guide app publishers to interesting or new content about app mining.
…On Thu, 23 May 2019, 21:26 Gina Abrams, ***@***.***> wrote:
Agreed on Awario, and is being addressed in #108
<#108>. Thanks for the
suggestions, I think emailing with most of this info makes a lot of sense
moving forward. Not sure how much we can share in tips on a monthly basis,
but good to take into consideration.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#110>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALBYWMVYI3UZWHLUAKRFQLPW3VV5ANCNFSM4HOT7R5Q>
.
|
@jehunter5811 At the start of every month PBC will send out an email to all registrants with the rules to be used for that month's app mining, including any big changes. Going to move this to done. If there are other issues not addressed by this, please open new issues. |
What is the problem you are seeing? Please describe.
Github is probably a perfecty fine place to handle proposals, but I see an increasing amount of information communicated via Github issue comments and not communicated elsewhere. And if they are communicated elsewhere, that place where they are communicated is not communicated itself.
Ok, that was sort of confusing. But let me give an example:
I found out that there was even App Mining documentation by reading comments on Github issues. Another example: I did not know where to find the spreadsheet of Awario data until I saw this issue #108. That issue specifically mentions multiple github issue comments where critical information is shared.
That's a poor way to communicate.
How is this problem misaligned with goals of app mining?
It creates an undue burden on app developers to crawl through every app mining issue to make sure they have not missed a comment with critical information.
What is the explicit recommendation you’re looking to propose?
Email has been working wonderfully for decades. Blockstack has every app miner's email address. Anything critical (meaning it impacts scores or has data that every app miner should easily be able to access) should be emailed.
** Describe your long term considerations in proposing this change. Please include the ways you can predict this recommendation could go wrong and possible ways mitigate.**
One difficulty I can see in this proposal is determining what info should be emailed and what shouldn't. I think the easiest approach is to simply email rule changes in their entirety (don't rely on the Changelog except for historical purposes) and email every piece of data that is supposed to be public information (i.e. links to the documentation explaining how scoring works for each reviewer, auditable data tables, etc).
The text was updated successfully, but these errors were encountered: