Opened 2 years ago

Closed 2 years ago

#27157 closed defect (fixed)

Update Tor FAQ - Tor has directory guards

Reported by: teor Owned by:
Priority: Medium Milestone:
Component: Webpages/Website Version:
Severity: Normal Keywords: easy doc, FAQ
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

https://www.torproject.org/docs/faq.html.en#EntryGuards says:

However, that feature won't really become useful until we move to a "directory guard" design as well.

But Tor has had directory guards for a long time now.

I think we can just delete that sentence.

Child Tickets

Change History (8)

comment:1 Changed 2 years ago by traumschule

Keywords: FAQ added
Status: newneeds_review

comment:2 Changed 2 years ago by teor

Status: needs_reviewmerge_ready

Thanks, looks good to me.

comment:3 Changed 2 years ago by traumschule

Thanks for reviewing this patch. Do you prefer to get this merged fast or shall I collect more FAQ related commits in the PR?

comment:4 Changed 2 years ago by teor

New tickets are cheap, and small changes are easy to review and merge.

So I recommend you open new tickets for each new topic (or new reviewer). And make a new commit for every change to a different section.

You should also ask hiro or whoever merges your work what they prefer.

comment:5 Changed 2 years ago by traumschule

Reviewer: hiro

I need to explain myself better. I titled the current pull request as work in progress with the intention to collect more commits, each fixing another issue referenced with '(fixes #bugnumber)'.
Instead I could open a new PR for each ticket, but then it's more work to review them in git I guess. Will wait to see what hiro thinks when she is back.

comment:6 Changed 2 years ago by irl

traumschule: I can't speak for hiro but I know that I prefer to review small changes. If you pile up a whole load of commits in one PR then I would probably ignore it until it's too old to consider rebasing it and then it would never be merged. Small PRs are easy to review and improve your chances that it is merged.

There are also quite a few people (I count 13 people) that can review and merge website changes, not just hiro. By setting the reviewer you will cause others that might have looked at your changes to ignore them until hiro is able to look at them. The reviewer field should really only be set by the person that is taking the review, or if you've already discussed with them the specific ticket.

If all the changes you're making are in the same file (like the FAQ) then you could put all these together in the same PR especially if they are each only small changes in that file. As soon as you start touching unrelated things this should always be in a separate branch. Even so, I could see that your first change could already be merged while you're still working on other changes. There is no reason to artificially cause delays here.

FWIW, commit e2e7bc6 looks good to me.

comment:7 Changed 2 years ago by traumschule

Reviewer: hiro

Thanks for the very helpful feedback, abandoning my WIP approach for this one.

comment:8 Changed 2 years ago by traumschule

Resolution: fixed
Status: merge_readyclosed

merged

Note: See TracTickets for help on using tickets.