[metrics-bugs] #21379 [Metrics/metrics-lib]: Metrics-lib web-site
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Feb 24 12:30:59 UTC 2017
#21379: Metrics-lib web-site
---------------------------------+------------------------------
Reporter: iwakeh | Owner: metrics-team
Type: enhancement | Status: new
Priority: Medium | Milestone:
Component: Metrics/metrics-lib | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------+------------------------------
Comment (by iwakeh):
Replying to [comment:4 karsten]:
> ..
> Another aspect is that we might want to include links rather than actual
contents on this page to keep this page static. For example, rather than
including the change log (which I suggested above, I know), it would be
easier to just include a link to the change log. Otherwise we'll have to
either update the website after a new release or automate that somehow.
We can always make it more complex later, I'd say.
Yes, better to start with links and static content.
>
> iwakeh, what do you think about the following sections:
Looks good, comment(s) below.
>
> - DescripTor - A Tor Descriptor API for Java (1 or 2 sentences with an
overview what it is, including CollecTor link)
> - Download (link to dist.tpo folder, most important steps for
verifying, link to change log)
> - Dependencies ("what you still need to get, or it just won't work";
hint: we don't need JUnit or Hamcrest, but we need Gson and SLF4j)
That should rather be part of the release Readme.md and of course will be
mentioned in the basic tutorial, but not a separate section.
> - Tutorials ("how you actually use it to get started")
> - JavaDocs (just the link, maybe with > as on CollecTor page)
> - Development (short paragraph with link to sources in gitweb.tpo, bug
tracker bugs.tpo, and team wiki page wiki.tpo, link to reproducible builds
doc in git when available)
>
> How should we work on the content? Should we check in the current
prototype as `index.html` and edit the content in Git, ideally with
separate commits for additions and removals? Or should we put it on a pad
and edit concurrently? Or should we first discuss sections and section
contents on this ticket before moving elsewhere?
I prefer the pad solution (the current content is an example and not
really useful in git history) and once we have an agreement there add all
to git for continuing in the usual way.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21379#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the metrics-bugs
mailing list