Talk:Main Page

From Unofficial BOINC Wiki

Jump to: navigation, search

Contents

[edit] Village Pump

This page became a discussion about the overall site, rather than just about the content of the page it is attached to. I'd like to move the site discussion to the Village Pump, which is the usual place for such things on MediaWiki sites.

Editors, please help move any topic here which remains of interest over to the Village Pump. Any topic which has outlived it's usefulness can be deleted (it's archived, after all, in the change logs).

Please start any new topic over at the Village Pump. --Eric Myers 18:31, 27 December 2007 (UTC)


[edit] Paul

There was a mention of the ability to do dynamic pages in the Wiki, I did not get into that as I had other fish to fry. I know my account will allow me to run CRON stuff but I havee not also tried to do that either. Since I am more worried about converting all of the open material to the WIki format I am not that interested in this problem.

I agree with John that it would be a nice feature to consolidate the information in one place so that ALL of the news feeds would show up here.

Anyway guys, I am pleased with how well it is working to this point ... I have been going back each day and looking at your corrections to my material, and the number of changes is runing about 200 a day roughly. I know a lot of those are minor, but still, that is pretty impressive. I am adding one or two pages of older material a day and we are getting close to having the Glossary done (still over a hundred terms, but I do about 5 a day) and the other site, UCB's is pretty close to being done too ... I only have about 20 pages there ...

Still looking for a guy to look into graphics and work on making those look good. I was hoping CaptainAvatar would be doing that, but I don't see any work from him yet... Also looking for more developers, so if you run into one ask him/her to jion the party. I would also like one less technical person, but the one I asked to audition has not returned his audition tape (as it were).

[edit] Misc. Thoughts

Hey Paul-

A few comments...

  • You mention your host providing cron support... how intent are you on sticking with this host? And how much is it costing you? I have more than ample server space and bandwidth (and server power) available at my disposal on the machine hosting BoincZilla.
  • I agree, we need to focus on getting everything in here and cleaned up before worrying *too* much about the RSS stuff - but RSS stuff would be nice, especially on the Community Portal we so far aren't utilizing. After I get back from my TDY, I can start thinking about implementing RSS reading in Mediawiki (and provide patches back to them...)
  • Progress definitly is being made.  :-)
  • What kind of graphics are you looking for, exactly? I can't do 'em myself, but I can probably push people like Tim to get them done.
  • It may just be my crappy DSL connection, but pages (especially page edits) are loading very very slow here... upwards of 30 seconds at times. Any ideas? Is it just the host, me, both, or what? I'd be lost without multiple tabs in Firefox... I just edit a few pages at once.  :-)

AthlonRob 21:24, 10 Jun 2005 (EDT)


I've just started looking at this site. I think the note at the top of the Main Page saying that the work is carried on "in memory of Paul" makes it sound like he's dead. Perhaps it can be rephrased? Just wanted to note that first impression.

Eric Myers 15:16, 2 May 2006 (BST)


[edit] More notes

I forget, it is about $40 a quarter. But it is PC based hosts, which is one of my long term gripes...

No one in their right mind (Paul's Opinion) uses a PC for a host that serves more than 2 people at a time. And, yes, I have noticed the slowness too ... I am not going to be able to get rid of the host anytime soon as I have all the old site on it too. So, it also may be because of the two loads ...

I am not wedded to ANYTHING ... Though how to make smooth transisitions is probably beyond me. I do own, or have the rights to several domains with the basic idea of BOINC-Doc ...

Almost all of the images I have are out of date. So, they need to be recaptured. even more, we need to work out the "look" and what works best. Since It takes several minutes to load them up and fiddle, well, it is not high on my list ... I mean, this is already wearing me out ... stupid of me, but I fret on how little I seem to get done each day ...

SO, for all that, I like the progress in an intelectual way ... my bones are arguing with me ... :( probably depression breaking free again ...


I am also still looking for a less technical person to look and comment/ edit ... are we pitched too high? Development, obviously is going to be higher, but, even there the material is incomplete, somewhat chaotic, and definately not enough for one person to get a system up and running with any confidence with how to do it. If there were, we would not see all the pleas in developers mailing list...

[edit] Project list templates

I changed this page and several related pages to use templates. If I found them all that means one edit will adjust the project lists in all places used. The Template names are: Current Project List, Other Project List, Beta Project List, and Alpha Project List. The template BOINC Powered Project List uses several of them. --JKeck 00:15, 5 Jul 2005 (EDT)

[edit] Templates

I have been using the extensively for message examples so we only have to make a change one place to "fix" mistakes. Same as what John did.

I have a few for tables too, common error codes, deadlines, etc.

There should be a way to make a list of templates or something, but I have not figured out the best way to do that ... it maybe I need a mechanical list.

Solved problem with templates listing. See full list at http://boinc-wiki.ath.cx/templates.php

--Chris - 24 May 2006 19:55 (BST)


[edit] SQL Errors

the SQL problems aren't completely fixed, when trying to search, all that is returned is an SQL error

i'll add a note to the front page Lee Carré 18:04, 23 May 2006 (BST)

Thanks. --Rytis 18:28, 23 May 2006 (BST)

Fixed. --Chris 20:00, 23 May 2006 (BST)


[edit] Comercial spam links

You opend the wiki for everyone and now we get links to buy flowers. They did'nt work and to delite one is not a lot of work, but what happend if they flood the wiki? -- Miko --

Then I assmue the configuration will be changed back to require users to have an account to be able to edit -- Lee Carré 08:35, 6 May 2007 (BST)

[edit] Bot attack.

If there is a bot attack on the UBW, then the edits will be reversed.

If it becomes severe, edits will be reversed, and all anon edits will be forbidden.

I will leave registration open in that case though. Unless the bots want to register, then that'll filter the bots out. -- Chris (06/05/07 16:52 UTC)

Lets hope MediaWiki has implemented a good CAPTCHA system. Automated bots are becomming quite smart, and considering this site uses MediaWiki, it's security will likely fail in much the same ways. -- Lee Carré 09:33, 13 May 2007 (BST)
I'm using the imagecaptcha system now. That should make it quite a bit harder for them to attack. -- Chris (20/05/07 07:41 UTC)

[edit] Simplifying the entry page

I'd like to suggest that we simplify the entrance page. As the first page anyone sees when they get to the wiki, it should simply tell them what the wiki is about, just in broad terms, and then direct them to the major division they are looking for.

Most BOINC volunteers need to get at client information, and don't need info about projects or development. There is no need to tell them a lot about those topics on the first page, and it's confusing. On the other hand, they do need to know those exists, just so they don't go there.

I really like the way MediaWiki handles this so I made up a draft which is a shameless copy of theirs.

Now maybe that page could get a little more text or perhaps news, links to useful things like recent changes, version, etc... I just want to start a discussion on how best to simplify the entrance page (and how to move things now on it to appropriate other places). -- Eric Myers 17:26, 26 May 2007 (BST)

Seems like a significant improvement on the content and usability fronts, however it would be preferential to use CSS instead of tables (for layout) for accessibility - eg, have the 3 main sections as an unordered list (in the markup), styled (with CSS) as desired: {list-style: none; float: left}.
Also adding a few inline links would be helpful without hindering readability:
  • "useful information about BOINC" in the site tagline pointing to more info about what BOINC is and does.
  • "BOINC client software" as well perhaps.
  • "BOINC projects" from a volunteer's point of view, info about projects etc. rather than how to create a project.
  • change the 2nd item "BOINC projects" to "project managers" or similar to make it clear who it's aimed at.
Removing un-needed words, such as "Please choose the section appropriate to your needs" - that's obvious, and just adds more text for the user to process -- Lee Carré 18:06, 26 May 2007 (BST)
I will play with the list style instead of tables. Thanks.
The second item is actually aimed at BOINC projects -- either the people who manage them or those who would like to set them up. But I see your point. The other two labels, "BOINC volunteers" and "BOINC developers", are for people, while "BOINC projects" does not really describe the role of an individual. And yet I think it's the right label, while "BOINC managers" doesn't quite carry the same meaning. Perhaps use "For BOINC volunteers", and "For BOINC developers" and leave the other as is? Or make it "Managing BOINC projects" ?
Perhaps there needs to be a quick summary first about what BOINC is -- assuming someone gets to the site but doesn't quite know what BOINC is. And links to the main site.
I think that "BOINC client software" would be the same as "BOINC volunteers". If there is a distinction we should make then it could be made on the next page one gets to.
I agree the words you want to strike are unnecessary. I just put something there because the page seemed too empty (whereas the current one is too full). -- Eric Myers 02:48, 27 May 2007 (BST)
The actual wording of various items it open to debate (the only way to really tell is user testing) but something more descriptive should do, my point was just that in it's current state, the "for projects" item didn't effectively convey who it was aimed at, again, making the visitor have to think about it. I gathered the actual meaning after some thought (having experience with BOINC, and being aware of the differences) however it also occoured to me that it is not immediately obvious that the "for projects" section is for projects & admins etc. - your suggestions for section names seem clear to me, however I strongly recommend reading some guidelines for writing microcontent, not that I can find fault with names you suggest.
Well, adding additional description is more text to process, the current summary of the boinc wiki seems perfectly fine, it's accurate and to the point. By having a link to more info about BOINC itself, visitors can find out more if they need/want to, while not hindering visitors who already know what BOINC is, but who might be unaware of what the BOINC Wiki is.
Again, what to use as link text is open to debate, and such decisions come from good information architecture planning (eg, site structure, content, navigation etc.).
Simplicity is generally good for usability (well, that's a simplification in itself, but is one of the ways to achieve good usability) or rather, not over complicating things; to most users it will be obvious that they have (and need to make) a choice based on the purpose of their visit. -- Lee Carré 06:55, 27 May 2007 (BST)
Actually, further to my previous comments about section names, having the first word as "for..." in each case would be less effective than having a different word as the first (simply dropping the "for" prefix) as the first few words are the most significant, if they're effective they greatly aid scanability (and thus usability).
As you can see, even small things aren't simple to design well -- Lee Carré 07:00, 27 May 2007 (BST)
Lee, I took your advice and converted from a table to lists. Please try it and see what you think. I'd like to invite you to come over to Pirates@Home and continue this discussion there, where it may get more attention. I can arrange for you to have write access to the wiki even without RAC there, or the talk pages are open to anonymous edits. --Eric Myers 03:08, 29 May 2007 (BST)
Certainly I'll continue discussion at pirates rather than cluttering up the wiki. I've made a new account at priates with an ID of 6274; a comment here or an email to my registered priates address to let me know when my account has been updated (and thus when i can post) will be fine (I have a different address for personal email though, my registered account is for mailing lists and spam lol, i'll reply to the confirmation email with my personal address).
Lee, welcome aboard. The discussion would actually be in the Pirates@Home discussion forum, not the wiki, though we can use that too. You will find a thread called "making a good impression" in the "Help!" forum. --Eric Myers 01:46, 4 June 2007 (BST)
Sorry for my lack of clarity, I ment continuing the discussion on the priates site in general (either forum or wiki) rather than the boinc wiki. But thanks, I'll get settled in my quarters and be on deck shortly Captain ;) -- Lee Carré 10:56, 5 June 2007 (BST)
While on the subject; is Pirates@home for discussion of other boinc related things too, because I've got a whole bunch of ideas for the boinc front-end web code (coding & implementation stuff, accessibility, usability, features etc.) and most of the front-end coding experience to implement them, problem is that i haven't leant PHP yet, so am finding it very difficult working in the CVS. -- Lee Carré 07:22, 3 June 2007 (BST)
Pirates@Home is sort of a Skunk Works for BOINC. It was started to prepare the way for Einstein@Home, and I've also used it to develop modifications to the discussion software for another LIGO related project, including mating a wiki to the BOINC discussion site so that the two can be used with only a single login. And there's a lot more. We will try out different ideas with the site software, and some of them then get moved into the main BOINC code. Some don't. I've developed a series of applications which are designed to make it easier for people to learn how to create BOINC apps, and I've also worked on an app which makes a wide range of screensavers available for use by any BOINC app.
So if you have some ideas for how to improve BOINC, either additional features or improvements to accessibility, or adding to the documentation, we'd love to hear them. There is a forum called "Wish List" just for such things. It's a little easier to communicate in that format than on a wiki talk page (I think), and there is likely a larger (at least somewhat) interested (at least somewhat) audience there. Welcome aboard. --Eric Myers 01:46, 4 June 2007 (BST)
Sounds excelent, and just the place to discuss many of my non-simple ideas with people willing/able to give feedback :) -- Lee Carré 10:56, 5 June 2007 (BST)

[edit] How to change the front page

Loving the new page, Eric. When you've finished tweaking, would you mind backing up the current front page, and inserting your new one. I was thinking about it myself the other week, but somebody beat me to it :) -- Chris 31/05/2007 07:17 BST
Sure, I'm glad you like it. I think the best way to do this is to export the page from Pirates to UBW and get it working, then you modify the wiki config to make that the new main page. The existing page still has the same name and is still around, and we could provide a link to it for people who had been accustomed to clicking through it.
But before doing this, I need to see if we don't also need to create or modify the three main pages we jump to. If it's just modification of existing pages then we can cut over and then edit. If we need new pages for those targets I'd like to create them first. --Eric Myers 17:29, 31 May 2007 (BST)
Unless I'm missing something, surely that's what the wiki SVN is for, to save old versions? lol. As in, if you want to view an old version, you just view the history, or to have a link to an old/previous version, you just make a link to that specific version, no? -- Lee Carré 07:22, 3 June 2007 (BST)
If we're doing restructuring, it might be an idea to restructure the main sections of the wiki.... Then again maybe not. If it's deemed a good idea, let's do it, otherwise keep the pages. I don't know how to set the main page name, yet.... but I'll work it out before too long.-- Chris 31/05/2007 20:16 BST
To change which page is displayed as the "main" page (the one people see when they jump it without an article title) got to Special:Allmessages, find the item "mainpage" and edit it to the topic (page name) you want to be the mainpage.

So the existing page will always be there (we can of course rename it to "Old Main Page") and any other page can be made to be the mainpage. But not yet. It now looks like the three sections implied by the new design each needs it's own new main page. --Eric Myers 01:46, 4 June 2007 (BST)

[edit] Overhaul

I did make an attempt at an overhaul and generally improving things a while ago, but I was slated for trying. If i'm brutally honest I'm not sure this site is as useful as some people think, or others would like it to be - the guide for something should be easier to understand than the thing it's trying to explain. There are many area's for improvement, accessibility and usability being the top two (which includes Google by the way, Google loves accessible content, but use HTML instead of XHTML, google doesn't yet support XHTML, nor does IE, and no browser supports XHTML sent as HTML ie text/html). -- Lee Carré 07:22, 3 June 2007 (BST)

Audience specific sub-sections will of course be needed, don't try and botch the current pages to fit, it won't work as well, each section needs to be custom writen, aimed at it's intended audience (eg, simple for beginners, lots of detail for developers) -- Lee Carré 12:16, 3 June 2007 (BST)

Lee, we don't mind you editing, just please use the preview button and only save if it's 100% necessary. To quote Rytis:
Who knows what can come to people minds. And multiple edits makes additional work.
Another reason is that it makes another copy of the page in the database. I don't know about Chris, but at Paul times it was very problematic with the db size.
I am sorry if I sounded wrong. It's a really bad day for me today. Your changes to the Wiki are really appreciated.
Please note his last comment. I really like the amount of work that people do here, but you do sometimes go a little over the top with edit counts. I mean, was it 100% necessary to make 7 edits to this discussion this morning..... I think not, please try editing the whole page to reply to multiple discussions. --Chris 03/06/2007 12:47 BST


I DO use the preview function, lots! I only commit changes once I'm sure.
  • Define "100% necessary", which of my edits do you deem "un-necessary" and why?
  • So you're after edits, but only certain types or quality of edits, that sounds very much like certain styles of government.
  • Show me a single written work created without any editing, any decent text is tweaked and improved, this is a technical problem stifiling the creation of good writing (which is what you need for something like a wiki isn't it?).
  • An SVN system (like the one the wiki uses) only saves a delta, that is; only the changes to a page, so it makes no difference. A whole copy of the page isn't saved for every edit. Prove me wrong.
I'm rather confident the software doesn't do this. Firstly, SVN is a source code management system, it does use binary differences when it saves between each revision, but it couldn't be used as a core system behind a web software, which I think you are implying, its just a seperate thing on its own. However MediaWiki source code itself is available for download via SVN. Secondly, I couldn't find a place that specifically says MediaWiki saves only the differences. I did find that it saves similar revisions in the same row and then compresses them together. This should mean that the compression algorithm will find all the redundancies in the data and compress it very well. Unlike SVN, where it is difficult to remove specific revisions because of the fact that the current revision depends on all previous ones, MediaWiki does allow you to do this easily in the form of the Oversight extension, which from looking at the source, simply removes a revision row on the database and inserts it in a 'hidden' table not accessible anywhere else in MediaWiki. --AlphaLaser 21:48, 5 June 2007 (BST)
  • If space is a problem; well databases generally only get bigger, so you'd run out eventually anyway.
  • If you took on a project like the BOINC wiki without the funds to afford slightly bigger disks, well, I'll buy one for you.
  • "Additional work"; it's your choice to monitor changes - so you trust me enough to submit edits, but not enough to let me edit without supervision?
  • The thing that really annoyed me about the way both Chris and Rytis handled the situation previously was that I had limitations applied to my account - and my account only, no-one else's - as soon as they noticed, like I was some naughty kid, no warning, no explanation first (I was unaware of the problem at the time). The conversation is on my talk page, you may need to view an older version if someone's been petty and decided to delete it. -- Lee Carré 11:54, 5 June 2007 (BST)


Chris, I disagree. Smaller edits which each address a particular issue or problem are better for organization. Each edit should have a descriptive summary line. If multiple edits puts an additional drain on the database then we do not have enough room for all the stuff I can imagine should go here, and we should address that separately. --Eric Myers 00:58, 4 June 2007 (BST)
Thankyou Eric :) This was exactly the problem when I tried editing this page as a whole, there's a maxlength="..." on the edit summary field. How would you know which edits applied to which section? Have either of you (that's Chris or Rytis) ever tried editing a page this long in a single go? Doubt it. -- Lee Carré 11:54, 5 June 2007 (BST)
I'm hardly running short on server space at present (5.3 GB free, 8.3 GB hard disk), but my main concern is the daily backup of the databases (which total some 239 MB (of which 46 MB are this wiki) will eventually cause an out of disk space problem somewhere, as I store backups for one month. Doing the maths there, that means 239 x 30 = 7170 MB of disk space on backups, a little over 7GB. When you add the weekly backup of /srv, that's another 850 MB, so add 850 x 4 = 3400 MB, which is 3.25GB, roughly. that's just over 10GB on backups alone. Add that to the weekly PC backup of 21-24GB, call it 22GB, and we get 90GB of data in backups. This data is all compressed, but even then it only goes down to 75GB. My backup drive is only 76GB in size, (claims 80GB) so we can't add much as it's on 99% full. Note that I need to upgrade this as it's several years out of date, but I don't have the cash to do this at the moment. In an ideal world, I'd have enough space to do full backups of both my desktop and the server onto one drive, but at the moment only the DB, Web pages, and my desktop's /home folder get backed up. When I get enough cash, I'm going to swap the 80GB disk for a 250GB disk, which should make things a tad more snappy, especially as I can then do a full backup much faster than at the moment (Long live SATA2). -- Chris 07:13, 4 June 2007.
Update, just discovered that i'm going to be getting another 250Gb HDD, which will go in my desktop, the 120Gb in there now will go in the server, giving us more free space than ever. -- Chris 17:09, 4 June 2007
I hate to point out the obvious, but 46MB divided by 75,000MB is about 0.06% - 6 hundredths of a percent! The few bytes (call it 1KB) I'm adding makes an unnoticable difference. Over 99% of your backup data comes from elsewhere, I'd start looking there first. If you're really stuck, backup to another server. -- Lee Carré 11:54, 5 June 2007 (BST)

[edit] Contact links

PS. Can we all change any contact links to use Special:ContactForm now, thanks. --Chris 31/05/2007 07:33 BST

Sure, but it's Special:Contact. I fixed this on the current front page. --Eric Myers 17:29, 31 May 2007 (BST)
Oops! -- Chris 31/05/2007 20:16 BST
A regular mailto: link should also be provided, firstly for accessibility, secondly so people can use their prefered email client (they may have special needs), I for one like to keep a copy of emails i send. Various methods of avoiding spam-bots are available, I recommend the numbered character reference method suggested by HoneyPot: how to avoid spam-bots which at present is effective against ~85% of spam-bots. Don't use JavaScript or image replacement methods, both of these are inaccessible. I can explain why if you're interested. -- Lee Carré 07:22, 3 June 2007 (BST)
Lee, I know precisely why you say that, but given that I don't have much in the way of filtering spam (plus I changed to a new e-mail address) I don't really want that being spammed up by the "every-kind-of-product" bots! If you see it as a 100% must, I'll set my mail server up with SpamAssasin, but I'd prefer not to as last time I got no mail for 4 days as it kept deleting it before it got to my mailbox! --Chris 03/06/2007 12:47 BST
What's to stop a bot filling in a form and sending you spam anyway? If spam is really that much of a problem, use a honeypot filtration/catching method, or try hosting one of the many mail address generation pages and linking to it from the contact page, the idea being to flood the spammers with thousands of useless addresses, might work. -- Lee Carré 11:19, 5 June 2007 (BST)
How about putting the contact address on the contact page? Then someone who wants to send via their own e-mail client can do so. The address can be munged so that it cannot be harvested by spammers, but can be cut/paste or read directly. I'm trying this on Pirates@Home (see the bottom of every page) and have not yet gotten any spam to that address. Lee, does this scheme cause any usability problems? --Eric Myers 00:58, 4 June 2007 (BST)
A plain-text address will most likely be picked up by spambots (it's just another address in the HTML source afterall, no difference to bots). Considering my previous point, you might as well just make it a link LOL. The method I linked to does exactly as you describe; "munges" the address to foil the majority of spambots (for now). Usability implications: well, the most obvious; it's not a clickable link, which annoys the hell out of users - or "visitors" as we're supposed to call them, lesser experienced users won't be aware that you can copy an adderss and paste it into your mail client, let alone know how to do that, hyperlinked addressed are a must. There are also accessibility implications; a screen reader will read out an address in full, and I'm sure it's much harder to copy & paste an address when using a screen reader (as is the case with most tasks), so having a link which automatically opens a new massage from your default mail client with the "To:" field already populated saves vast amounts of time for visually impaired and sighted users alike. -- Lee Carré 11:19, 5 June 2007 (BST)

[edit] Pretty permalinks for better Google visibility

What about configuring MediaWiki to use pretty links for all the articles instead of the ".../index.php?title=..." stuff. This should also significantly improve ranking in search results. - Torben Schreiter 04:13, 29 May 2007 (BST)

Mostly done -- Chris 31/05/2007 07:13
Full URLs should still work, or preferably permantly redirect to the shorter version so as to not break links and avoid dreaded link-rot (think how many links are in the various forums), -- Lee Carré 06:35, 3 June 2007 (BST)


[edit] Embedded Stats

This is just a thought for a neat extra feature. I don't think external image linking is on here, but even if not, it would be neat to be able to embed a stats signature just for our user pages. This could be done via a parser hook. Being a fan of BOINCstats an example would be <boincstats>user_805748</boincstats> which would appear as an embedded image of my signature. Likewise it can be done for the other stats sites. It would even be nice to be able to pull the raw data directly from an XML so it can be displayed as text but I think this would end up using too much effort and/or server load. The parser hook can be designed so it only works on the user space so we don't see people's stats in the main namespace. If interested and need help with the parser hook (I've made one like this myself) just let me know. Thanks. . --AlphaLaser 06:43, 4 June 2007 (BST)

I'll have a word with Rytis about this. Thanks for offering. -- Chris 06:58, 4 June 2007
This could be of general use to any wiki. The best way to make such a thing of general use would be to make it an extension. See MediaWiki: Extensions. Then it would be easy for any wiki admin to enable this feature by turning on this extension. I'd be willing to help turn the parsing hook into an extension if you need it, but if you've already taken care of the hook you may already know how to do this. I'd be happy to test it out on the wiki at Pirates@Home first. --Eric Myers 13:26, 4 June 2007 (BST)
Sorry to say that it's been vetoed. If we add one, we have to add all of them, and I'm afraid we're not prepared to spend the time or effort to make this work, and it's just waaay too much work for myself and Rytis to get our heads around. Besides, this is the Unofficial documentation, not the stats collection. Sorry AlphaLaser. Nice idea, but not here please. -- Chris 17:32, 4 June 2007
This is too bad. Like Eric said, another wiki might find this useful. If they do or if there's a change in the decision, I've put the source code and instructions for installation on the wiki. View the example page to see how it looks. The code supports BoincStats/MundayWeb/BoincSynergy at the moment, I can add support for other sites if need be. Feel free to use and modify the code as you see fit. Thanks again. --AlphaLaser 21:03, 4 June 2007 (BST)
Ah, it is an extension already. Nice. We could play with it on the Pirates wiki. As Chris and Rytis point out, they are too busy to have to do too much on this, and it should work for all sig sites. So it should be generalized to work with any of the sig sites, present and future. It should be configurable to a list of allowed sites. I'd suggest only one parser hook for a new tag, and that one should get a URL with a pattern pointing to the sig site, with a way to substitute the $User or CPID. But this is way off topic for this page, so how about moving this over to the Wish List on Pirates@Home? --Eric Myers 21:51, 4 June 2007 (BST)


[edit] New Documentation Forum

I recently asked David and Rom to create a new forum just for documentation issue on the Berkeley site, and they have done so.

I'd like to move meta-discussion about this site over there, as well as other documentation sites. The "talk" pages for each wiki page are still available, but the discussion should be confined to the contents of that page, and we clearly needed a better venue for overall discussions about how to organize BOINC documentation.

See y'all there... --Eric Myers 16:42, 5 June 2007 (BST)

Oh, could we also have a web dev forum? Currently there's nowhere public to discuss web dev issues. -- Lee Carré 17:38, 5 June 2007 (BST)

There is also a separate section there already for web development. --Eric Myers 20:59, 5 June 2007 (BST)

I guess that would be at the Web interfaces forum. --AlphaLaser 21:49, 5 June 2007 (BST)
Ah, OK didn't realise that was for web dev in general, probably because it doesn't seem to be used very much. — Lee Carré 09:16, 9 June 2007 (BST)
Personal tools