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

[Rich Brown]

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...

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?
- Or do we use the 'draft' facility? (How?)


>> 	- 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...

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.

>> 	- 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...

>> Curating: The current site makes it seem as if all pages are equally important. I feel the urge to do the following:
>> 	- Categorizing the "List of Wiki Pages" for a project (e.g., http://bufferbloat.net/projects/cerowrt/ ) 
>> 		so there's a sense of their importance
> 
> A way to do this would be to update the 'index' wiki pages to be more
> useful (e.g. https://www.bufferbloat.net/projects/cerowrt/wiki/) and
> keep the overview pages as a 'complete' list. However, it's certainly
> also possible to mark some of the pages as 'important' and have those
> show up on top of the list.
> 
> 
>> 	- Discard old/outdated/useless articles
> 
> 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.

>> Workflow:
>> 	- Rules for making posts: Who can make them? How do they get
>> 	published?
> 
> Well, it's a git repo. I figure anyone can do pull requests.

Certainly. This is one of the items that I wanted to be sure we discussed. Dave also mentioned that we might be comfortable giving core authors permission to edit. That would give more direct access for making small tweaks/corrections.

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...)

>> 	- 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?

>> 	- I see the 404 handler in place, but it doesn't seem to show a
>> 	link to archive.org
> 
> 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.

>> 	- Is there a way to do page redirection? It looks as if Toke has done a great job of replicating
>> 		URLs in the new site, but if we see frequent broken
>> 		links, is there a way to redirect a page to its
>> 		equivalent on the new site?
> 
> Yes. This is already used for news items and issues.
> 
>> 	- Should we add a Google search box on 404 page? On every page?
> 
> Not sure what it takes to do this properly, and if it's worth the
> hassle.
> 
>> 	- Would it make sense to review error logs from time to time?
> 
> 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.

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.

Thanks all!

Rich