peterhelmenstine
commented
5 months ago Would request we get data on the usage for floor and suite usage. Sounds like it's pretty small, in which case we can remove them if they're not being used.
Open martinhannigan opened 6 months ago
peterhelmenstine
commented
5 months ago Would request we get data on the usage for floor and suite usage. Sounds like it's pretty small, in which case we can remove them if they're not being used.
grizz
commented
5 months ago Regardless of what we do here, this should be reviewed in the field drops for #625
mcmanuss8
commented
5 months ago +1 but dropping field is pdb 3.0
martinhannigan
commented
5 months ago +1
On Thu, Jan 4, 2024 at 12:16 PM mcmanuss8 @.***> wrote:
+1 but dropping field is pdb 3.0
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877477097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQWKMQRHEVOJSLGWWVDYM3PXRAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGQ3TOMBZG4 . You are receiving this because you authored the thread.Message ID: @.***>
stillwaxin
commented
5 months ago I would encourage the discussion around why these fields are not being used as much as they could be. Is it because users do not believe the data to be valuable? I would suggest that is untrue as floor and suite information can be found usually in "Address 2" when present. Perhaps thought should be placed around deprecating / removing Address 2 and migrating the information there into either Floor or Suite field (or rename Address 2 to "Floor or Suite" and merge the information from existing Address 2, Floor, and Suite fields into the one, or just get rid of Floor/Suite and keep Address 2 but in the UI display as "Address 2, Floor, or Suite" or something along those lines). Here are some sample facilities in which Floor or Suite information is shown in Address 2 : https://www.peeringdb.com/fac/283 https://www.peeringdb.com/fac/71 https://www.peeringdb.com/fac/775
Do we know what was the original impetus around the creation of these 2 fields and does the reasoning then still hold now?
On Thu, Jan 4, 2024 at 12:39 PM Martin Hannigan @.***> wrote:
+1
On Thu, Jan 4, 2024 at 12:16 PM mcmanuss8 @.***> wrote:
+1 but dropping field is pdb 3.0
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877477097>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AFA2YQWKMQRHEVOJSLGWWVDYM3PXRAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGQ3TOMBZG4>
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877507198, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAEFWE2WQQCHR7YGWD3YEDYM3SNLAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGUYDOMJZHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
martinhannigan
commented
5 months ago Hey Michael, good comments. If its not clear, we're talking about ORG objects. Check out the examples in the opening.
/ORG/
https://www.peeringdb.com/org/1187 https://www.peeringdb.com/org/34 @.*** https://github.com/mustangthz your geocode needs editing!) https://www.peeringdb.com/org/7483
HTH, and thank you!
Martin
On Thu, Jan 4, 2024 at 1:16 PM Michael Still @.***> wrote:
I would encourage the discussion around why these fields are not being used as much as they could be. Is it because users do not believe the data to be valuable? I would suggest that is untrue as floor and suite information can be found usually in "Address 2" when present. Perhaps thought should be placed around deprecating / removing Address 2 and migrating the information there into either Floor or Suite field (or rename Address 2 to "Floor or Suite" and merge the information from existing Address 2, Floor, and Suite fields into the one, or just get rid of Floor/Suite and keep Address 2 but in the UI display as "Address 2, Floor, or Suite" or something along those lines). Here are some sample facilities in which Floor or Suite information is shown in Address 2 : https://www.peeringdb.com/fac/283 https://www.peeringdb.com/fac/71 https://www.peeringdb.com/fac/775
Do we know what was the original impetus around the creation of these 2 fields and does the reasoning then still hold now?
On Thu, Jan 4, 2024 at 12:39 PM Martin Hannigan @.***> wrote:
+1
On Thu, Jan 4, 2024 at 12:16 PM mcmanuss8 @.***> wrote:
+1 but dropping field is pdb 3.0
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877477097>,
or unsubscribe <
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877507198>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AGAEFWE2WQQCHR7YGWD3YEDYM3SNLAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGUYDOMJZHA>
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877554322, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQR7E4NO2XW474STQA3YM3WXTAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGU2TIMZSGI . You are receiving this because you authored the thread.Message ID: @.***>
stillwaxin
commented
5 months ago Ah yeah my bad. Same thoughts may still apply? I suspect just removing these and moving/merging any data currently located in Floor/Suite into Address 2 may make the most sense but welcome other thoughts/ideas. Would someone like Equinix ever split a fac and use the field like in Chicago for this "facility" (actually 3 suites/floors but occupies a single record: https://www.peeringdb.com/fac/7 For more accurate data it should be split and be represented as a campus it seems. In that case does anyone care what the field is called that contains "Floor 5" or 6 or 8? I suspect not.
On Thu, Jan 4, 2024 at 1:22 PM Martin Hannigan @.***> wrote:
Hey Michael, good comments. If its not clear, we're talking about ORG objects. Check out the examples in the opening.
/ORG/
https://www.peeringdb.com/org/1187 https://www.peeringdb.com/org/34 @.*** https://github.com/mustangthz your geocode needs editing!) https://www.peeringdb.com/org/7483
HTH, and thank you!
Martin
On Thu, Jan 4, 2024 at 1:16 PM Michael Still @.***> wrote:
I would encourage the discussion around why these fields are not being used as much as they could be. Is it because users do not believe the data to be valuable? I would suggest that is untrue as floor and suite information can be found usually in "Address 2" when present. Perhaps thought should be placed around deprecating / removing Address 2 and migrating the information there into either Floor or Suite field (or rename Address 2 to "Floor or Suite" and merge the information from existing Address 2, Floor, and Suite fields into the one, or just get rid of Floor/Suite and keep Address 2 but in the UI display as "Address 2, Floor, or Suite" or something along those lines). Here are some sample facilities in which Floor or Suite information is shown in Address 2 : https://www.peeringdb.com/fac/283 https://www.peeringdb.com/fac/71 https://www.peeringdb.com/fac/775
Do we know what was the original impetus around the creation of these 2 fields and does the reasoning then still hold now?
On Thu, Jan 4, 2024 at 12:39 PM Martin Hannigan @.***> wrote:
+1
On Thu, Jan 4, 2024 at 12:16 PM mcmanuss8 @.***> wrote:
+1 but dropping field is pdb 3.0
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877477097>,
or unsubscribe <
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877507198>,
or unsubscribe <
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877554322>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AFA2YQR7E4NO2XW474STQA3YM3WXTAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGU2TIMZSGI>
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877561976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGAEFWFSNBJUV7VPJWQBTD3YM3XMPAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGU3DCOJXGY . You are receiving this because you commented.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
martinhannigan
commented
5 months ago That's exactly where we went with it too. We have a little more work to do before finalizing the method. Good catch though!
On Thu, Jan 4, 2024 at 4:32 PM Michael Still @.***> wrote:
Ah yeah my bad. Same thoughts may still apply? I suspect just removing these and moving/merging any data currently located in Floor/Suite into Address 2 may make the most sense but welcome other thoughts/ideas. Would someone like Equinix ever split a fac and use the field like in Chicago for this "facility" (actually 3 suites/floors but occupies a single record: https://www.peeringdb.com/fac/7 For more accurate data it should be split and be represented as a campus it seems. In that case does anyone care what the field is called that contains "Floor 5" or 6 or 8? I suspect not.
On Thu, Jan 4, 2024 at 1:22 PM Martin Hannigan @.***> wrote:
Hey Michael, good comments. If its not clear, we're talking about ORG objects. Check out the examples in the opening.
/ORG/
https://www.peeringdb.com/org/1187 https://www.peeringdb.com/org/34 @.*** https://github.com/mustangthz your geocode needs editing!) https://www.peeringdb.com/org/7483
HTH, and thank you!
Martin
On Thu, Jan 4, 2024 at 1:16 PM Michael Still @.***> wrote:
I would encourage the discussion around why these fields are not being used as much as they could be. Is it because users do not believe the data to be valuable? I would suggest that is untrue as floor and suite information can be found usually in "Address 2" when present. Perhaps thought should be placed around deprecating / removing Address 2 and migrating the information there into either Floor or Suite field (or rename Address 2 to "Floor or Suite" and merge the information from existing Address 2, Floor, and Suite fields into the one, or just get rid of Floor/Suite and keep Address 2 but in the UI display as "Address 2, Floor, or Suite" or something along those lines). Here are some sample facilities in which Floor or Suite information is shown in Address 2 : https://www.peeringdb.com/fac/283 https://www.peeringdb.com/fac/71 https://www.peeringdb.com/fac/775
Do we know what was the original impetus around the creation of these 2 fields and does the reasoning then still hold now?
On Thu, Jan 4, 2024 at 12:39 PM Martin Hannigan @.***> wrote:
+1
On Thu, Jan 4, 2024 at 12:16 PM mcmanuss8 @.***> wrote:
+1 but dropping field is pdb 3.0
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877477097>,
or unsubscribe <
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877507198>,
or unsubscribe <
. You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
— Reply to this email directly, view it on GitHub <
https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877554322>,
or unsubscribe <
. You are receiving this because you authored the thread.Message ID: @.***>
— Reply to this email directly, view it on GitHub < https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877561976>,
or unsubscribe < https://github.com/notifications/unsubscribe-auth/AGAEFWFSNBJUV7VPJWQBTD3YM3XMPAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGU3DCOJXGY>
. You are receiving this because you commented.Message ID: @.***>
-- @. ~]$ cat .signature cat: .signature: No such file or directory @. ~]$ cat .disclaimer All opinions are my own and do not represent any of my employer. @.*** ~]$ cat .pronouns He/Him
— Reply to this email directly, view it on GitHub https://github.com/peeringdb/peeringdb/issues/1482#issuecomment-1877788841, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFA2YQVE367K2ZPB6ZUCFF3YM4NWZAVCNFSM6AAAAABANAJ6KWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXG44DQOBUGE . You are receiving this because you authored the thread.Message ID: @.***>
leovegoda
commented
5 months ago Summary
Is your feature request related to a problem? Please describe.
As part of the ORG profile, the user is provided two places to zero in on the ORG's location. The record is able to take "Floor" and "Suite". One could presume that 99.99% of ORG objects are offices. They are not provided the option to specify a postal option like PO BOX for a virtual office.
Here's a sampling.
https://www.peeringdb.com/org/1187 https://www.peeringdb.com/org/34 (@mustangthz your geocode needs editing!) https://www.peeringdb.com/org/7483
ORG is clearly trying to tell a viewer where the corporate office is or how to reach it either for a communication, a visit or even sending a letter or package.
Who is affected by the problem?
Peering DB users
What is the impact?
Duplicated data entry. Wasted disk space. Wasted processing. Confusing output.
Are there security concerns?
No
Are there privacy concerns?
No
Describe the solution you'd like
Add Suite to Floor so it reads "Floor or Suite". In most buildings I've been in globally, the suite starts with the floor and ends in the office location on the floor the first fraction of data provided. Change Suite to PMB or POBOX or whatever suites us for a match or close to match for global consistency if possible.
Do you think this feature will require a formal design?
No
Describe alternatives you've considered
Doing nothing. If we do nothing there's no harm. If we do something there's improvement.
What is the proposed priority?
Low priority
Provide a rationale for any/all of the above
Accuracy and consistency in language and building nomenclature.
Additional context
Does not appear to impact other objects as it's a form change for an object.