Sam Ruby wrote on 4/27/17 9:57 AM: > On Sun, Apr 23, 2017 at 9:20 PM, Shane Curcuru <[email protected]> wrote: >> I'd like to setup the homepage on whimsy.a.o to get semi-automatically >> built, so that when new tools are deployed for use, they get displayed >> on the homepage. Note: this is opt-in, and probably semi-automatic, so >> we don't have the homepage breaking without a developer noticing first. >> >> My possibly naive concept is to annotate each script that we would link >> to with a # comment on the second line of the script: >> >> # Wvisible:Category This is the link description >> >> Then have a tool script that crawls the www/ tree, and outputs a copy of >> the homepage with auto-generated links put into Category sections, >> similar to the current layout. >> >> Thoughts? Better ways to annotate? > > Not sure it is worth it, but am welcome to be proven wrong. :-)
I think it would be valuable also if there were a funky way that _whimsy_footer could output a "Related tools to this page" that keyed off of the category. So when someone is using members/nominations, it could list members/memberless-pmcs, which would help make various tools more useful since users would find out about them. > > I don't know of any prior art. OK, was wondering if there was some super-simple ruby doc format that I should use the format of, or just makeup a simple one-line comment format. > > The one thing I would be strongly opposed to is your specific > suggestion above: allowing tools to write to the www tree, > particularly a tree that enables the running of cgi scripts would be a > security exposure. Duh, you're right, I do not want to do that. > Now the front page could be a script itself. And with how fast > machines are these days, it could even crawl the entire site on every > request. I was going to start with a tool that generates content someone could periodically dump into the homepage manually; that's plenty automated for me. I'd feel bad the server would keep getting tired if the front page were generated instead of tired. 8-) > >> We are at the point that while we do have many different individual >> tools, we also have a lot of useful tools that many different people >> might be interested. Better publicizing them can help some Apache >> communities. > > I agree with the statement of the problem above. I disagree that the > effort required to add a single line to the home page is a significant > inhibitor, but again, I welcome the opportunity to be proven wrong. > > I think the bigger problem is a social problem. We are all gun shy. > We write scripts and mark them as test or don't publicize them and in > many cases aren't even sure that they are a good idea. Then a > percentage of them take off and build a following and take on a life > of their own. So I should embrace change, even chaotic change, and just check scripts into sensible directories instead of hiding in /test? <lol> > I think we need to embrace the fact that most tools aren't mission > critical, and may break occasionally. Obviously there are a few tools > that are notable exceptions: > > * If the roster tool is broken for more than a day, the > infrastructure team workload may go up > * If the secretary workbench is broken for more than a few hours, > the secretary will get understandably cranky. +1: Pro Tip: do not break the secretary's workflow. > * If the board agenda tool is broken in the days leading up to a > board meeting, quite a few people will get upset > >> -- >> >> - Shane >> https://www.apache.org/foundation/marks/resources > > - Sam Ruby > -- - Shane https://www.apache.org/foundation/marks/resources
