[Bloat] Bufferbloat.net - Organizing, curating, and workflow

[Toke Høiland-Jørgensen]

Rich Brown <richb.hanover at gmail.com> writes:

> Good comments all... Let me preface these responses by saying that I'm
> willing to help out, but don't want to get in the way of the rapid
> progress being made.
>
> Toke: Let us know when you think you're done with major
> reorganizations...

Awesome. I think I'm done with most of the reorganisation stuff now, and
am happy to let other people go nuts :)

> I also want to see if there's consensus about when and how to make
> updates, so that we're not stepping on toes. TL;DR questions:
>
> - Do we only want to use pull requests, or should core authors have
> edit access to github?

Quite happy to give out push access. Only caveat is that there needs to
be an understanding that updates should be tested and if someone breaks
something it is going to break on the live site. However, I figure the
people involved here knows how to deal with that ;)

> - Or do we use the 'draft' facility? (How?)

My thought was that for most things (like news articles, etc), just
writing it up and pushing it 'live' is the right thing to do. But there
may be cases where several people want to explicitly collaborate on,
say, a news article before it is published, in which case the draft
facility can be a way to use the git repo to do this. Using branches
would be another.

>>> 	- Is there a way to display newest entries? I'd like to see a
>>> 	sidebar element showing the 5 newest posts
>> 
>> Yes, certainly. Was thinking of putting a list of newest news items on
>> the front page. However, for the wiki pages it is not necessarily
>> obvious that having a notion of 'newest' is useful.
>
> I see the (new) News column on the home page. The content is right,
> but it takes too much space on the page. Maybe there could be a box
> above the "Find us elsewhere" panel that just had news article
> titles...

Hmm, I do tend to use fairly wide monitors. Can certainly move it if it
takes up too much space. Feel free to play around with it :)

> Random updates to the wiki pages wouldn't need to be mentioned. But if
> there's a new topic added, maybe we should publish a corresponding
> News item to call it out.

I think it's possible to do a 'new items' feed that uses only initial
publication date as the sort key; which would make new wiki pages show
up as well, but not edits of old ones.

>>> 	- Can an RSS feed be generated automatically?
>> 
>> Yes, but see above.
>
> I wonder whether an RSS icon could go in the heading of the News
> panel...

Sure. Just link it to /projects/index.xml - there's already a <link
rel=alternate> in the header.

>> Yes, this is probably needed. And also fixing broken links (see the
>> issue I opened for this on github).
>
> I figure that members of this group can take on sections as the spirit
> moves them.

That was my hope ;)

> I suspect bigger experiments should be done as PR's (especially if we
> figure out how to use github.io pages to display the new form of the
> site from our own repos...)

Yeah. For local experiments, running 'hugo serve' is all you need. For
things that need review, just publishing the files somewhere is all that
is needed. If we end up needing to have a long string of review on some
new feature (say), it is also possible to host automatic builds from
other branches at some other location.

>>> 	- Auto-publish - if it's not already happening, could we
>>> 	re-render and publish after a commit?
>> 
>> Yes, that is certainly possible. For now I figure I'll do it manually
>> (it's just re-running a script), but if we get enough activity that that
>> becomes a bottleneck, I can certainly set up something automated.
>
> Cool! It looks as if you added code to do that. Is it operational?

Yup. Had some more time last night and set it up. It will automatically
pull and build from the master branch whenever it changes. Takes less
than a minute from push to live update :)

>> It includes a javascript from archive.org which *should* show a link if
>> (and only if) an archived version exists. Haven't verified that it
>> actually works.
>
> Ahah! I think this is going to be hard to test - Toke has done too
> good a job of matching Hugo URLs to the old Redmine URLs... :-)
>
> I did fire up LinkChecker on the site, and it found a few bad URLs.
> I'll send a separate message about it.

Saw that in the logs. I am including a filtered error log below, listing
the wiki URLs that seem to be missing.

>> Possible. Split out the logs to a separate file; can provide it if
>> someone wants to go digging. Or I can just parse out a list of 404
>> errors from time to time.
>
> I know how to add Google Search, and can take it on after other stuff
> has settled.

Awesome.

> Given the good match between new and old URLs, we might only need a
> one-time survey of error.log files to see if there's major traffic to
> a particular "lost" page.

See list below.

-Toke

$ grep 404 /var/log/nginx/bufferbloat.access.log | awk '{print $7}' | sort | uniq | grep wiki | egrep -v 'annotate|history|diff|edit|png|version=|jpe?g'    
/login?back_url=http://www.bufferbloat.net/projects/wisp6/wiki/Wiki
/projects/bismark/wiki
/projects/bismark/wiki/Capetown
/projects/bismark/wiki/Mac_Instructions
/projects/bismark/wiki/Wiki
/projects/bismark/wiki/Wndr3700v2
/projects/bloat/wiki/ARP
/projects/bloat/wiki/bql_enabled_drivers
/projects/bloat/wiki/Bufferbloat_and_Freeswitch_Conference_Call_March_9/needthelink
/projects/bloat/wiki/Daddy_why_is_my_Internet_Slow_Today
/projects/bloat/wiki/Dark_Buffers
/projects/bloat/wiki/Dogfood_principle
/projects/bloat/wiki/experiment-fun_with_your_switch
/projects/bloat/wiki/index
/projects/bloat/wiki/introduction
/projects/bloat/wiki/mitigations_and_solutions_for_broadband
/projects/bloat/wiki/Mitigations_and_solutions_for_Home_Gateways
/projects/bloat/wiki/Papers/href=
/projects/bloat/wiki/technicalintro
/projects/bloat/wiki/todo
/projects/bloat/wiki/VoIP
/projects/bloat/wiki/VOIP/m2e-delay.PNG
/projects/bloat/wiki/What_(bad)_stuff_happens_on_a_congested_network
/projects/bloat/wiki/Wiki
/projects/cerowrt/wiki/BloatLab_1/
/projects/cerowrt/wiki/BloatLab_1/attached_t.svg
/projects/cerowrt/wiki/cerowrt_flashing_instructions
/projects/cerowrt/wiki/CeroWrt_flashing_instructions
/projects/cerowrt/wiki/evaluating_qos_behavior
/projects/cerowrt/wiki/Experiment_-_QoS
/projects/cerowrt/wiki/fq_codel_on_wireless
/projects/cerowrt/wiki/Installation_guide
/projects/cerowrt/wiki/ipv6_tunnel
/projects/cerowrt/wiki/Newer_versions_of_fq_codel
/projects/cerowrt/wiki/Paris
/projects/cerowrt/wiki/Pre-33_Releases
/projects/cerowrt/wiki/Setting_Up_SQM_for_CeroWrt_310
/projects/cerowrt/wiki/uftp
/projects/cerowrt/wiki/Wiki
/projects/cerowrt/wiki/wondershaper_must_die
/projects/codel/wiki/best_practices_for_benchmarking_codel_and_fq_codel
/projects/codel/wiki/Best_Practices_for_Benchmarking_CoDel_and_FQ_CoDel
/projects/codel/wiki/howto
/projects/codel/wiki/index
/projects/codel/wiki/rrul_test_suite
/projects/codel/wiki/Wiki
/projects/codel/wiki/Wiki/
/projects/iscwrt/wiki/
/projects/iscwrt/wiki/Wiki
/projects/make-wifi-fast/wiki/Wiki
/projects/projects/bloat/wiki/BQL_enabled_drivers/
/projects/projects/cerowrt/wiki/CeroWrtScripts/
/projects/projects/cerowrt/wiki/Debugging_CeroWrt/
/projects/projects/cerowrt/wiki/Enable_ECN/
/projects/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat/
/projects/projects/cerowrt/wiki/SQM/
/projects/projects/cerowrt/wiki/Wondershaper_Must_Die/
/projects/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel/
/projects/projects/codel/wiki/Bobbie/
/projects/projects/codel/wiki/Cake/
/projects/uberwrt/wiki
/projects/uberwrt/wiki/Experimental_patches
/projects/uberwrt/wiki/Hardware_evaluation