-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Collect layer information #317
Collect layer information #317
Conversation
@jywarren, I have collected the information for all layers and have added a short text in One of the layers had mentioned 'near real-time' data and some others mentioned 'real-time' or 'current' data. Is it okay to classify them all under 'near real-time'? We could display these layers as For data validity and reliability, we could add an exclamation icon for each layer which would open up a modal containing information about the data. The text under disclaimer in the JSON file would go in the modal. Mockup: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!!!
I had also looked for links for reporting information for layers that accept community submissions. Only the odorreport layer had a link that directly pointed to a form. Opensense and Purpleair layers accept sensor data but one has to register or sign in to do so. Pfas layer has an email where people can send in a report if a site was missing in the data provided by them. Do I include them all in the menu so that users are directed to those pages if they want to submit a report? or do we display the report option only for odorreport layer? |
I like the icon! What about an (i) icon for info, instead?
And for the reporting, I think we can link to whatever the first step is in
reporting, so for PA do they have a signup page? Or even just purpleair.com?
Let's cast a wide net!
Awesome!
…On Mon, Dec 23, 2019, 10:33 AM Renisha Christie. A ***@***.***> wrote:
I had also looked for links for reporting information for layers that
accept community submissions. Only the odorreport layer had a link that
directly pointed to a form. Opensense and Purpleair layers accept sensor
data but one has to register or sign in to do so. Pfas layer has an email
where people can send in a report if a site was missing in the data
provided by them.
Do I include them all in the menu so that users are directed to those
pages if they want to submit a report? or do we display the report option
only for odorreport layer?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#317?email_source=notifications&email_token=AAAF6J2ISJXWYBHX54B2PCDQ2DK5ZA5CNFSM4J6VFNCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHRLJYQ#issuecomment-568505570>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6J3HYKO7QHNHUFNDCKLQ2DK5ZANCNFSM4J6VFNCA>
.
|
Bumped version indicating minor change. |
Yes, they have a register page.
That'd be great! We could use the info circle icon from fontawesome. https://fontawesome.com/icons/info-circle?style=solid |
Information gathered in this PR related to this Issue #138. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Shall we merge this?
@sagarpreet-chadha, I was thinking about npm versioning in LEL and began wondering if the changes we have contribute to a major change instead of a minor one? We've changed the hashing library used and changed the location of the lib folder as well. Wouldn't this be a breaking change? Just wondering here. Please correct me if I am wrong. What are your thoughts on this? |
Hi! Usually the definition of breaking is if a downstream library which
depended on this one would cease to function correctly unless refactored
--- in that sense the version is a signal to them not to use this new
version until they've confirmed the refactor, or they risk their code
breaking. So, unless we change what we've "promised" in the readme, in
terms of functions, usage, etc, it shouldn't be a breaking change. Hope
this helps!!
…On Mon, Dec 23, 2019, 11:21 PM Renisha Christie. A ***@***.***> wrote:
@sagarpreet-chadha <https://github.com/sagarpreet-chadha>, I was thinking
about npm versioning in LEL and began wondering if the changes we have
contribute to a major change instead of a minor one? We've changed the
hashing library used and changed the location of the lib folder as well.
Wouldn't this be a breaking change? Just wondering here. Please correct me
if I am wrong. What are your thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#317?email_source=notifications&email_token=AAAF6J4YU3NMVXKMS76G2ZDQ2GE4LA5CNFSM4J6VFNCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHSOBHA#issuecomment-568647836>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAF6J7NO7GGFPD7NVU4XHLQ2GE4LANCNFSM4J6VFNCA>
.
|
@jywarren, thanks for explaining it to me! I think I get it. I may have to do a bit more reading on the topic to become comfortable with it. 😄 |
Fixes #316 (<=== Add issue number here)
Make sure these boxes are checked before your pull request (PR) is ready to be reviewed and merged. Thanks!
@publiclab/reviewers
for help, in a comment belowIf tests do fail, click on the red
X
to learn why by reading the logs.Please be sure you've reviewed our contribution guidelines at https://publiclab.org/contributing-to-public-lab-software
Thanks!