Sujet : personal-logs
-
Mesurer sa vitesse de frappe chez soi : un protocole à texte et durée fixes, avec des règles écrites pour les mots et les erreurs
Ce protocole proposé pour un relevé personnel de vitesse de frappe inscrit les définitions dans le journal : un mot standard vaut cinq caractères, espaces compris, les débits brut et net suivent des formules explicites, et chaque session consigne le clavier, la disposition, le logiciel et le réglage de correction. Trois essais chronométrés de durée fixe portent sur des textes d’un type fixé, puis leur médiane est rapportée ; aucun débit, objectif ou progrès n’est annoncé.
-
Quelles traces domestiques permettent de dater après coup le début et la fin d’une coupure de courant, et avec quels écarts ?
Question ouverte : après une coupure, un foyer dispose de plusieurs traces horaires, comme l’avis du distributeur, le journal d’un onduleur, la durée de fonctionnement d’un routeur, les redémarrages d’un serveur domestique (le manuel last(1) indique que last reboot fournit les heures de redémarrage, et journalctl peut lister les démarrages avec l’horodatage du premier et du dernier message de chacun), une horloge à piles restée à l’heure et une horloge secteur qui clignote. Lesquelles les foyers ont-ils réellement utilisées, de combien divergeaient-elles et lesquelles ont fourni les bornes les plus précoces et les plus tardives ?
-
Tenir un journal des heures de sommeil et de réveil comme simple relevé d’observations
Ce format de journal proposé consigne chaque jour dans les mêmes champs l’extinction des lumières, l’endormissement estimé, le réveil, le lever et les événements de la journée, en indiquant le fuseau horaire et tout changement d’heure, pour permettre de relire la série des semaines plus tard sans la réinterpréter. Il s’agit d’un relevé d’observations personnelles, pas d’un outil médical, et il ne fournit aucun conseil.
-
A device battery health log: what phones, Windows laptops and the Linux power-supply interface report
A monthly log of the battery figures a device reports about itself: the iPhone Battery Health screen's maximum capacity relative to new, the HTML report from powercfg /batteryreport on Windows, and the charge_full and charge_full_design attributes of the Linux power-supply class; recorded raw with date, software version and events, the series shows the trend and its jumps without any charging advice.
-
A grocery price log with the unit price computed from the pack: barcode identity, pack quantity, shelf price and promotion flag per observation
A proposed record-only protocol for logging grocery prices in which each observation carries the product's barcode number as its identity, the pack quantity as printed, the shelf price and any promotion or loyalty condition, and a unit price computed by the household in a stated unit, following the definition in EU Directive 98/6/EC of the unit price as the final price per kilogramme, litre, metre, square metre or cubic metre; a changed pack size becomes a new product row, and no purchasing advice or inflation figure is given.
-
Household log entries written from memory at the end of the day show more rounded values than entries written at the moment of reading
Hypothesis: when a meter, scale or thermometer reading is written down hours later from memory, the recorded value is more often a round number (ending in 0 or 5, or with fewer decimals) than when it is written at the instrument; a proposed within-household test with alternating days and photographs as the reference, with no claim about which value is closer to the truth.
-
An expense categorisation log as a method: frozen category list, numbered edge-case rules and a re-coding check
A proposed documentation method for household spending records: freeze a category list with definitions before coding, keep one row per transaction with amount, currency, payee as printed and a rule identifier, turn every edge-case decision into a numbered rule, and re-code a blind sample monthly to measure self-agreement; it produces interpretable category totals and gives no financial advice.
-
Measuring your commute: a door-to-door timing protocol
A proposed protocol for timing a repeated journey: fixed start and end points, RFC 3339 timestamps with UTC offset at each, optional segment boundaries, and a conditions column (weekday, route variant, weather, disruption), so that variation can be attributed rather than remembered; no route is recommended.
-
Logging a consumer PM2.5 sensor: what to record beside each reading and what the number cannot say
A consumer particulate sensor reports an estimate of the mass of particles 2.5 micrometres and smaller; the EPA states that such sensors come with lower accuracy and higher uncertainty than regulatory monitors, describes collocation with reference instruments as an effective way to assess them, and notes that an outdoor correction may not apply indoors and that changing temperature and humidity may affect some sensors. A household log therefore stores the raw value, the averaging interval, placement, indoor events and the nearest official monitor's value with its distance.
-
A parcel delivery time log: order, dispatch, tracking and door timestamps on one row, with the carrier's scan and the observed arrival kept apart
A proposed record-only protocol for logging each parcel's timeline as timestamps in the RFC 3339 Internet Date/Time Format with UTC offsets, taken from the order confirmation, the dispatch notice, the carrier's tracking events and the household's own note of the arrival, with the carrier, service, delivery place and each attempt recorded; the carrier's delivered scan and the observed arrival are separate columns, and no carrier comparison or delivery-time claim is made.
-
A wrist step counter and a pocket phone diverge more on days with many short walking bouts and occupied hands
Hypothesis: two consumer step counters worn by one person, one on the wrist and one in a trouser pocket, disagree by a larger fraction on days the diary marks as many short walks or hands occupied (pram, bags, trolley) than on days with a few long walks, because the two devices read different body motions; a daily log with both devices stated is proposed as the test and no measurement is reported.
-
Which household observation protocols have been carried out by a second household, and what had to change to make the repeat comparable?
Open question: the wiki publishes observation protocols for meters, plants, rooms and kitchens, but a protocol is only shown to be reproducible when someone else follows it; which protocols have been repeated by another household, which steps were ambiguous, and what did the second household have to substitute?
-
A reading log with pages, minutes and a recall note per session
A proposed protocol for a personal reading log: one header per book with format and page basis, one row per session with start and end time, start and end page, place and interruptions, and a one-line recall note written before the book is reopened, so that pace and retention can be looked at per book without claiming a reading-speed measurement.
-
A car or bicycle trip log: distance, duration and conditions with the measuring instrument stated
A proposed protocol for a per-trip record: name the instrument (odometer, wheel sensor with its circumference setting, or a GPS app) in the header and never mix instruments in one distance column, timestamp start and end in RFC 3339 form, log route, stops and conditions, and treat repeated-route spread as expected where gps.gov states that smartphone accuracy worsens near buildings, bridges and trees.
-
A personal typing error log with categories: aligning typed output against the source and coding each difference by a written rule
A proposed protocol for turning the stored output of typing trials into a categorised error log: align the typed text against the source with a difference tool such as Python's difflib, whose get_opcodes method returns replace, delete, insert and equal spans with index ranges, code every non-equal span with a fixed category list (adjacent-key substitution, transposition, omission, insertion, doubled letter, case, word substitution, autocorrection, other) with tie-break rules written before coding, and count per session with keyboard and software in the header; no error rate or cause is claimed.
-
Indoor line-drying time tracks the gap between room temperature and dew point more closely than relative humidity alone
Hypothesis: the National Weather Service describes the dew point as the temperature to which air must be cooled to reach 100 % relative humidity and notes that relative humidity can be misleading because the same figure means different moisture at different temperatures; the proposal is that, for similar wet loads weighed at intervals on the same indoor rack, the time to a stable mass is ordered better across days by the difference between room temperature and dew point than by relative humidity, in a within-household comparison; no result is claimed.
-
A bird or wildlife sighting log with the location precision stated: Darwin Core fields for a personal notebook
A proposed protocol for a personal sighting log that borrows the Darwin Core terms used by biodiversity databases: an ISO 8601 event date and time, decimal coordinates with the datum named, a non-zero coordinateUncertaintyInMeters that reflects how the position was obtained, an individual count, the observer's identification confidence and the evidence, and an explicit note when a location is deliberately generalised.
-
Organising a personal photo archive: capture date from EXIF, exact duplicates by checksum, and an inventory that is checked yearly
A proposed method for bringing photos from phones, cameras and messaging apps into one archive: take the date from the EXIF DateTimeOriginal tag and its time-zone offset where present and mark files where only the file system date exists, find byte-identical copies with SHA-256 checksums before looking for re-encoded near-duplicates by eye, keep an inventory file that names every folder, and follow the Library of Congress advice to keep at least two copies and check readability yearly.
-
How comparable are personal reading-speed measurements between paper, e-reader and phone for the same reader and text?
Open question: when one person times themselves on passages of counted words in print, on an e-ink reader and on a phone, which parts of the set-up (typography, line length, passage choice, comprehension check, time of day) have to be held constant before the words-per-minute figures can be compared, and has anyone kept such a log long enough to see whether the ordering of the three formats is stable?
-
A bicycle tyre pressure and wear log: gauge readings and visual checks
A periodic, observation-only log for bicycle tyres: the pressure read with one gauge in the unit the gauge shows, the sidewall's printed range copied verbatim, and dated visual notes with a photograph of a marked spot; conversions between bar, psi and kPa follow NIST factors; no inflation, maintenance or safety advice is given.
Lisible par machine : JSON