Ticket #91 (closed task: wontfix)

Opened 3 years ago

Last modified 2 years ago

anonymous

Reported by: jkk Assigned to: somebody
Priority: critical Milestone: milestone1
Component: component1 Version:
Keywords: <Key> Cc: painting

Description

turn off router lights manually or automatically during set times. possibly use the AOSS/SETUP/etc. buttons for it

for those who need invisible routers.

Change History

05/29/2007 03:44:22 PM changed by eko

  • status changed from new to closed.
  • resolution set to wontfix.

They're not all controlled by software. LAN and WAN leds can't be turned off. Not fixable. Hmmmm, yes, it is: use black tape.

07/06/2007 09:54:48 PM changed by anonymous

  • cc set to painting.
  • component changed from component1 to component2.
  • summary changed from (temporarily) turn off router lights to painting.
  • priority changed from trivial to blocker.
  • version set to 2.0.
  • milestone set to milestone1.
  • keywords changed from led indicator lights option to painting.

08/04/2007 10:55:34 AM changed by anonymous

  • component changed from component1 to component2.
  • summary changed from painting to anonymous.
  • priority changed from blocker to critical.
  • version set to 1.0.
  • milestone set to milestone1.
  • keywords changed from painting to <Key>.

08/06/2007 10:35:05 AM changed by anonymous

  • priority changed from critical to trivial.
  • type changed from enhancement to defect.
  • milestone deleted.

08/06/2007 03:44:39 PM changed by anonymous

  • priority changed from trivial to minor.
  • version deleted.

08/16/2007 03:03:37 PM changed by anonymous

  • priority changed from minor to critical.
  • version set to 1.0.
  • type changed from defect to enhancement.
  • milestone set to milestone1.

08/17/2007 03:47:49 PM changed by anonymous

  • priority changed from critical to minor.
  • component changed from component2 to component1.
  • milestone deleted.

08/17/2007 05:11:33 PM changed by anonymous

  • priority changed from minor to critical.
  • version deleted.
  • type changed from enhancement to task.
  • milestone set to milestone1.

09/15/2008 04:06:04 PM changed by add

Many things are transparently clear for a dev but unclear for an end user. This is why I think it is a different community which should take care of the docs than which develops the code. Of course the app maintainer has to check for vandalism correctness and his cool hidden feature missing for releases, but the docs can be generally worked out by end users who would like to contribute and start to use docs to learn cool stuff about their apps in the first place. Both annotations and contributions will only clutter the interface by default as a design pattern rather than trying to put it all together. That way you can never create offline or print docs of high quality without again having the devs or current admins maintain the comments and annotations. Hopefully a small Wiki quality team will evolve (i am against ops or admins) to review and summarize the contributions. I hope this gives us more users as contributors than having the docs focused on the devs. Cheers, duns china tour Apparel shoes bags Kitchen Food and Wine Furniture) Flowers and Gifts Wall Art Computer Components I still prefer a wiki like approach since the php (or mysql) docs are very cluttered when you have to take their comments in account. On the other hand they are professionally maintained imho, since they are *much* better than KDE documentation. KDE is by far larger and has so many different apps, which need screenshots and end user not dev/api docs, that more help is needed as long as the devs prefer to code than to write nice docs. And it is their choice to some degree imo. Technically interested but non-dev end users, which are plenty out there, are the users of and the best contributers to the docs, since they know what to write about. And they are certainly more than devs