Difference between revisions of "Space-labeling-draft"

From Technologia Incognita
Jump to: navigation, search
(Design)
Line 45: Line 45:
 
* Red: Item is marked for removal
 
* Red: Item is marked for removal
  
The scheme's description does not list
+
The scheme's description does not list exactly how things get moved from one state to another, however.
 +
This is where this page comes in handy.
 +
 
 +
From this point, I will refer to any of these colored labels as 'parking tickets' or 'tickets'.
 +
Any other label involved will be marked as 'label'
 +
 
 +
Tickets should preferably contain a unique ID to be able to refer to them. The supposed scheme anticipates that this will be done through PRE-PRINTED labels, with sequenced numbers and/or ticket-types in there too .(G-0001 green, R-0666 red label 666, etc)
 +
 
 +
=== Green tickets ===
 +
These tickets should be on items that have been given the 'go' by the maintenance-committee or board to stay in the space for longer periods of time.
 +
They are:
 +
* NOT placed on inventory (items of the space)
 +
* NOT placed on other space-owned items
 +
* placed BY a maintenance-committee-member
 +
* Likely a member-project, loan or otherwise.
 +
 
 +
They contain:
 +
* Owner/contact (if same)
 +
* Date ITEM was placed
 +
* End date of ticket
 +
* Date TICKET was placed
 +
* Person who placed ticket (maintenance-committee-member)
 +
 
 +
They should:
 +
* be checked by maintenance-committee upon regular intervals to check for expiry
 +
* preferably also be entered into a digital system so as to be able to be notified of expiries
 +
* NEVER be placed or altered by people other than maintenance-commitee UNLESS upon special agreement
 +
* be linked to any project/item/etc page on the wiki related to it.
 +
 
 +
=== Blue tickets ===
 +
Blue tickets are placed on items found without any clarity as to what they are and/or who they belong to and/or how long they will be there for.
 +
 
 +
They are:
 +
* Placed on any non-identifiable item, without inventory-label or project-label or otherwise
 +
* Placed by ANY member
 +
 
 +
They contain:
 +
* Date ticket was placed
 +
* Person who placed ticket (contact)
 +
* Date ticket was found by maint-com
 +
* Person of maint-com who found ticket
 +
* Free-text info for person PLACING ticket
 +
* Free-text info for person to RESPOND to ticket
 +
 
 +
They should:
 +
* Be checked for whenever there is a maintenance-committee day; adding it to wiki and/or resolving it
 +
* preferably directly also be entered into a digital system to track their progress
 +
* be notified about to the members mailing-list by the maint-com whenever a new one was found.
 +
 
 +
=== Orange tickets ===
 +
 
 +
Orange tickets are to notify people of a BROKEN or HAZARDOUS state of an item found in the space. As a warning, as a remark, as a request for replacement/fixing
 +
 
 +
They are:
 +
* Placed by any member who finds an issue with an item; safety-wise or related to completeness, functionality, etc.
 +
 
 +
They contain:
 +
* Date ticket was placed
 +
* Person who placed ticket (contact)
 +
* Date ticket was found by maint-com
 +
* Person of maint-com who found ticket
 +
* Free-text info of ticket-placer about issue
 +
 
 +
They should:
 +
* be checked for whenever maint-com does an inspection-round in the space
 +
* be reported and/or logged somewhere , pref on maint-com page, for progress
 +
* be included in maint-com report to mailinglist
 +
* result in item getting RED ticket (dispose) or repair/replacement
 +
 
 +
=== Red ticket ===
 +
 
 +
Red tickets are there to aid in the process of getting rid of things. They are placed on items by the MAINT-com and should lead to getting the item removed OR rehabilitated in some way (like someone repairing it, or re-purposing it)
 +
 
 +
They are:
 +
* placed by maint-com when it is clear an item is not going to be of any further use to the space OR are simply not able to be kept due to space/resource-restrictions
 +
* preferably the result of careful process, from BLUE to RED or ORANGE to RED for example.
 +
* they are kept on an item for a certain period of time to give people time to respond/react/act.
 +
 
 +
They contain:
 +
* Date ticket was placed
 +
* maint-com person who placed it
 +
* Date of intended removal
 +
* Description of intended removal ( space, dead, unmaintainable, abandoned..etc.. Could be made formal list)
 +
* free-form comment from maint-com : optional destination (trash, sell, etc)
 +
* free-form info-box for person to respond in.
 +
* contact-box for person to contact about it.
 +
 
 +
They should:
 +
* be checked for whenver maint-com does an inspection-round in the space
 +
* be reported on whenever a NEW one is placed
 +
* be reported on whenever an EXISTING one changes status
 +
* be reported on whenever an EXISTING one is acted upon (removed from space in any way)
 +
* be listed on the wiki
 +
* have a CLEAR process related to it, that is not deviated upon; either date-wise or process-wise.
 +
 
 +
== Labels ==
 +
 
 +
Labels are different from TICKETS in the sense that they are part of a project, inventory, etc, and do not change over the course of an item's stay in the space.
 +
They should contain info about OWNERSHIP and INTENT on them, as well as perhaps other aspects related to the item.
 +
Since a LABEL is a more long-term thing, it makes sense to keep track of these on the WIKI as much as possible, using semantic media-wiki to refer to 'inventory', 'project' or even 'infra' or such in some way.
 +
 
 +
It is proposed to have labels pre-printed with an ID that can be linked to inventory/project/etc through a simple look-up. Perhaps even a QR-code with URL and id pre-filled. The LABEL should also contain basic info:
 +
* What is the item called (also the name on the wiki)
 +
* What is the item's ownership-status (on loan ? space-owned ? member-project ?)
 +
* What is the item's INTENT (Use as is ? Alter at will but keep intact ? Use for parts ? Do Not Hack ? etc)
 +
 
 +
They should:
 +
* give a way to identify the item (if unclear)
 +
* give a way to find more info on the item
 +
* give direct clarity as to what is permitted
 +
* be placed by board/maint-com/tool-guardians
 +
* be announced publicly when placed (preferably)
  
 
= Gorgobal =
 
= Gorgobal =

Revision as of 20:04, 19 September 2021

Justa

What

The hackerspace has become more and more full with tools, gear, projects over the years. Some of this is a good thing, but it presents challenges. Ownership of items is sometimes unclear, as well as the status of the item in the space. Is it inventory ? Is it maintained ? Is it donated 'junk' that can be re-purposed ? Is a new tool that appears in the dirty room in a functional state at all, or did someone leave it there in the hope that 'someone' will fix it ?

Since ownership and status is unclear, nobody is really feeling entitled to take ownership of the situation when they find something 'abandoned', or just broken. What to do ? Who to inform ?

A system is proposed here to address some of these issues through interaction between labelling, processes, documentation.

Goals

The design goals of the proposal outlined below are the following:

  • When you find an item, it should be clear 'what it is'. Where 'what' includes:
    • Ownership (Space-owned ? PRivate ? Who ?)
    • Status (inventory, private project, donated hackable-stuff, etc)
    • Usability (functional ? Broken ? Dangerous ?)
  • It should be possible, through following a process, to find a way to get rid of (unwanted/broken) items
    • It should be transparent just how the procedure works, before, during and after its application
    • It should give enough time for owners/involved-parties to come forward
  • It should be easy and inviting to apply parts of the process to encourage its adoption
    • Labeling/adding should be almost 'free' in terms of labor involved.
    • Unlabeled, un-identifiable things should carry a 'penalty' in some form, giving an incentive
  • Any 'identification'-scheme (labels, writing, qr-code, rfid, whatever) should allow for integration to other processes/tools.
    • Allows for re-use of data, cross-linking.


Design

A proposed design to enable all of the above design-goals is listed here.

In short:

  • Items are assumed to be labeled by default
  • Unlabeled items will enter a process with identification and labeling as the end-goal
  • It should be possible for any member to start this process, either directly or indirectly
  • The process should be 'trackable', preferably on a mailinglist.

Method:

Another hackerspace (forgot name/link), has a system where they use colored labels as 'parking tickets'.

  • Green: Item is 'approved' for staying. Has a reference and end-date listed
  • Orange: Item is defective/broken. It serves as warning
  • Blue: Item is un-identified at current.. People are requested to come forward and help get it identified
  • Red: Item is marked for removal

The scheme's description does not list exactly how things get moved from one state to another, however. This is where this page comes in handy.

From this point, I will refer to any of these colored labels as 'parking tickets' or 'tickets'. Any other label involved will be marked as 'label'

Tickets should preferably contain a unique ID to be able to refer to them. The supposed scheme anticipates that this will be done through PRE-PRINTED labels, with sequenced numbers and/or ticket-types in there too .(G-0001 green, R-0666 red label 666, etc)

Green tickets

These tickets should be on items that have been given the 'go' by the maintenance-committee or board to stay in the space for longer periods of time. They are:

  • NOT placed on inventory (items of the space)
  • NOT placed on other space-owned items
  • placed BY a maintenance-committee-member
  • Likely a member-project, loan or otherwise.

They contain:

  • Owner/contact (if same)
  • Date ITEM was placed
  • End date of ticket
  • Date TICKET was placed
  • Person who placed ticket (maintenance-committee-member)

They should:

  • be checked by maintenance-committee upon regular intervals to check for expiry
  • preferably also be entered into a digital system so as to be able to be notified of expiries
  • NEVER be placed or altered by people other than maintenance-commitee UNLESS upon special agreement
  • be linked to any project/item/etc page on the wiki related to it.

Blue tickets

Blue tickets are placed on items found without any clarity as to what they are and/or who they belong to and/or how long they will be there for.

They are:

  • Placed on any non-identifiable item, without inventory-label or project-label or otherwise
  • Placed by ANY member

They contain:

  • Date ticket was placed
  • Person who placed ticket (contact)
  • Date ticket was found by maint-com
  • Person of maint-com who found ticket
  • Free-text info for person PLACING ticket
  • Free-text info for person to RESPOND to ticket

They should:

  • Be checked for whenever there is a maintenance-committee day; adding it to wiki and/or resolving it
  • preferably directly also be entered into a digital system to track their progress
  • be notified about to the members mailing-list by the maint-com whenever a new one was found.

Orange tickets

Orange tickets are to notify people of a BROKEN or HAZARDOUS state of an item found in the space. As a warning, as a remark, as a request for replacement/fixing

They are:

  • Placed by any member who finds an issue with an item; safety-wise or related to completeness, functionality, etc.

They contain:

  • Date ticket was placed
  • Person who placed ticket (contact)
  • Date ticket was found by maint-com
  • Person of maint-com who found ticket
  • Free-text info of ticket-placer about issue

They should:

  • be checked for whenever maint-com does an inspection-round in the space
  • be reported and/or logged somewhere , pref on maint-com page, for progress
  • be included in maint-com report to mailinglist
  • result in item getting RED ticket (dispose) or repair/replacement

Red ticket

Red tickets are there to aid in the process of getting rid of things. They are placed on items by the MAINT-com and should lead to getting the item removed OR rehabilitated in some way (like someone repairing it, or re-purposing it)

They are:

  • placed by maint-com when it is clear an item is not going to be of any further use to the space OR are simply not able to be kept due to space/resource-restrictions
  • preferably the result of careful process, from BLUE to RED or ORANGE to RED for example.
  • they are kept on an item for a certain period of time to give people time to respond/react/act.

They contain:

  • Date ticket was placed
  • maint-com person who placed it
  • Date of intended removal
  • Description of intended removal ( space, dead, unmaintainable, abandoned..etc.. Could be made formal list)
  • free-form comment from maint-com : optional destination (trash, sell, etc)
  • free-form info-box for person to respond in.
  • contact-box for person to contact about it.

They should:

  • be checked for whenver maint-com does an inspection-round in the space
  • be reported on whenever a NEW one is placed
  • be reported on whenever an EXISTING one changes status
  • be reported on whenever an EXISTING one is acted upon (removed from space in any way)
  • be listed on the wiki
  • have a CLEAR process related to it, that is not deviated upon; either date-wise or process-wise.

Labels

Labels are different from TICKETS in the sense that they are part of a project, inventory, etc, and do not change over the course of an item's stay in the space. They should contain info about OWNERSHIP and INTENT on them, as well as perhaps other aspects related to the item. Since a LABEL is a more long-term thing, it makes sense to keep track of these on the WIKI as much as possible, using semantic media-wiki to refer to 'inventory', 'project' or even 'infra' or such in some way.

It is proposed to have labels pre-printed with an ID that can be linked to inventory/project/etc through a simple look-up. Perhaps even a QR-code with URL and id pre-filled. The LABEL should also contain basic info:

  • What is the item called (also the name on the wiki)
  • What is the item's ownership-status (on loan ? space-owned ? member-project ?)
  • What is the item's INTENT (Use as is ? Alter at will but keep intact ? Use for parts ? Do Not Hack ? etc)

They should:

  • give a way to identify the item (if unclear)
  • give a way to find more info on the item
  • give direct clarity as to what is permitted
  • be placed by board/maint-com/tool-guardians
  • be announced publicly when placed (preferably)

Gorgobal

Proposal 2

Space-Labeling-Draft.svg

Items can have several states in the space, indicated by different colored labels. This proposal differs from proposal 1 in that it differentiates between space and member owned objects.

Space-owned

Means that this object is property of the space. Ideally this means some instructions or information of the object can be found on the wiki. This also means that the board, maintenance committee, or anyone they appoint to do so can throw this object out without delay.

Donated objects automatically become property of the space.

Space property will be marked with a GREEN tag.

Member-owned

Property of a member should be marked as such. If a object is marked for removal, the relevant space-member will be contacted. This category includes loaned objects. A Blue tag should contain the nickname of the member.

Member property will be marked with a BLUE tag.

Marked for removal

The space maintenance committee or the board can tag a object for removal. Objects marked for removal will be marked with a RED tag. A picture of the object will be placed on the wiki, and a mail will be send to @members . Objects marked for removal get a 1 month grace period. This is when members can ask if the object can stay. This is when a object can be marked to become either member- or space-property.

After the 1 month grace period, the object either becomes property of the space, or will be removed.

Ownership unclear

When ownership is unclear, it will be marked for removal. If no one claims the object, it can become space-owned or it will be thrown away.


In the future, these tags can include a link to the wiki with documentation on the object.