So after talking about nomination earlier it quickly became clear that actually before we could set a team up we needed to know what it was doing!
There are some initial thoughts here, and as the discussion moves on I will update this post. Some things to think about are:
- Shedule for clearing the backlog
- What actually needs to be tested
- How is the work going to be split up
- How much responsibility and power should the head have
- When is it right to move an app between stages
- What is the minimum number of people needed to test before we can be happy
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
we need to get going on this. My thoughts are:
I think a team of about 7 people to start with, one of whom would be the team leader. The remaining 6 would then be split into two subteams of 3. The subteams in discussion with the team leader would pick one app per week (or more if they wanted) and then after the subteam had tested the app and were happy the leader would give everything a check and then post approval to move up to the next stage. I think having three pairs of eyes on each app should be enough to catch most things. This format would allow us then to scale up with another group of 7 and so on.
The backlog will need quite a bit of work, even doing two apps per week it will take a while, I don't think there is any way around this though. To be fair I think we should start with the most recently updated apps from the list here. I will update the list now so we can start from a clean list again.
Anyone else have any thoughts? I expect I will add some more later
So, basically, (with some additions):
Alpha Team Head (example):
Developer 1
Alpha Bravo Team:
Developer 2
Developer 3
Developer 4
Alpha Charlie Team:
Developer 5
Developer 6
Developer 7
And then possibly add a team of three every now and then, and for every two teams added add another head of those two teams and add another weekly app requirement for those teams (Group 1 would work on one app, group 2 another, etc.).
Though, if they're all working on the same app, why are two teams needed? Where does John fit into this?
aren't, the two sub teams work on one each or we will never get through the backlog
And John carries on working on 2.0 and just digitally signs and uploads the releases as they are ok'ed by the head.
Ah, I see now. I misunderstood.
Scribus is currently listed as "outdated". This is incorrect. 1.3.3.14 is the current STABLE release. 1.3.6 is the current BETA release. Accordingly, please move Scribus back to the test release table, and note that I will be releasing Scribus Portable 1.3.6 soon.
that was my mistake, can you post issues about the page in that pages comments in future though? Thanks ::)
I've got to love the weekend - it gives me a chance to return to online life for a day or two.
I like your idea for 3-man sub-teams reporting to a team leader; I do have a couple of changes to make, though.
First, getting apps approved. I think we should do this similar to The Portable Freeware Collection's way of getting apps added to their database: each member has a certain rank, which can be increased by getting apps accepted to the database. Each app needs 10 votes to be accepted to the public database; since each member can have a maximum rank of 5, this means at least 2 people approve of the app.
The way I think this should be applied here is as follows:
* John and Chris have a rank of 10 (so anything they OK is immediately approved)
* All other devs start with a rank of 1
* Every time a developer gets 2 apps publicly released, their rank goes up by 1. (I also think this should be retroactively applied, so devs with already-released apps automatically get a rank increase)
* All devs other than John & Chris can have a maximum rank of 5
This way, as on TPFC, developers gradually earn more of a say in the release of an app as they prove themselves. I also think raising the rank by 1 every time the developer gets 2 apps publicly released is a reasonable raise rate: in order to make it to 5, a developer has to get 8 apps publicly released. That should be quite enough to ensure the developer's competence.
The maximum rank of 5 means that at least two developers will have to look at each app, so even if one dev misses something, another other might catch it.
With regard to the backlog, toss it my way in June. If my anticipated schedule holds, I'll be partly available starting June 6, and fully available from June 13 until the end of the summer. I'll be happy to deal with apps on the backlog, especially if one more person volunteers to partner with me on that.
A couple of thoughts on time commitments & app commitments: I don't think 6 months is a reasonable time period to have people commit to. Over the past few months alone, there's been a lot of coming and going; no matter how carefully planned something is, real life is sure to interfere at some point. I'm more in favor of a 3-month commitment which could be temporarily excused in case of emergency.
I also think an app a week is pretty reasonable, but a bit more flexibility might be nice. For example, I'm sure some of you will be going on summer vacation for a week or two, perhaps without Internet access. An average of an app a week is probably better equipped to handle situations like that; this way, a member who knows he's going to be AFK for a week can just do 2 apps the previous week or 2 apps the next week.
Just my 2¢; hope it's helpful!
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
We can't do what PFC does because we have quite a different setup. We actively make apps portable. We don't just take work that someone else has done and sign off on it. PFC subscribes to the 'mostly portable' theory (as long as it runs portably and you can move it around, it's 'portable') whereas we follow the portable app definition which requires apps not to leave things behind, be in a specific format, update MRU lists, settings can't break, etc. Additionally, PFC just links to apps done by others.
While this approach would work for apps produced directly by publishers, for apps we do ourselves, we need to check them out a bit deeper. Is it open source? If so, can we get the source and host it on SF easily? Is it trademarked? Have we gotten permission? Is it closed source? Do we have permission to repackage it? Will they host it or will we? Etc
So, while just signing off and listing something is simple over at PFC, we have a bit different standard (and a lot more legal checking). We don't want to turn into one of the me-too portable software sites that repackages apps illegally. We want to be 100% legal, 100% portable.
Sometimes, the impossible can become possible, if you're awesome!
I didn't mean we should become like PFC; I meant their ranking system is, IMHO, a good way of doing the release team. (Ironically, you're saying this won't work because we need to "check apps out a bit deeper", yet this is exactly what the ranking system would, at least in theory, accomplish)
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
agree with you on the flexibility, if you want to work on more app I wouldn't stop you
I think that the average should be at least one per week though. I also agree with three months not six, as mentioned previously.
The main issues I have with ranking people is that we don't have the infrastructure in place to do it, nor I suspect would anyone have the time to create it. It also seems a little unfair to rank people like that, for example technically I have one released app, yet having been here since the start I like to think I have a pretty good grasp on what is happening. I might just be feeling defensive though...
Why not? If there's a page listing the release team members, why couldn't we just add a column next to the release team list showing the user's ranking? Something like this (hope Drupal leaves my spacing alone):
Release team member Rank
User 1 3
User 2 5
User 3 1
I know. That's the biggest problem with rankings like that. There's also a lot of devs who have high-quality apps in the release queue, and they'd be somewhat crippled too.
Perhaps a variation of the ranking system, where active members receive some rank increase, would help remedy the problem.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
a good idea. I like it and think its reasonable.
Another thing I think is a must is the test on different OSes. So one has to make sure the group of 3 has XP/Vista/7 and maybe Wine to test the Apps with admin/limited and maybe guest accounts.
EDIT:
"One App per week" is making me think. Thoroughly testing Apps and maybe rewriting stuff might take longer than one week. I, having updates to watch out for myself, think it might be a little much. We do have a long list of waiting Apps but we dont need to get through them so fast I think. Quality before quantity. Which brings me to my second point: How do we choose the Appps to test? Oldest Apps first? or most wanted Apps first? How do we define "wanted"? How has an eye on the fact that it would be good imho to have some balance in the App list;i.e. not only games and utilities...
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Which is why I think Freemat and Maxima (I should get on that...) should be a few of the first ones tested.
EDIT: And I agree, one app a week is a bit much.
A lot of people don't have multiple systems to check on (for example, I'm only on XP), so the release sub-teams would have to be at least partially decided by the computer systems each member has at their disposal.
There's also developers (Steve Lamerton, wraithdu, and myself are just 3 that come to mind) who have their own apps to work on.
And don't forget the real-life part of the equation; we can't plan for the "ideal" scenario, because the odds of it happening are approximately 0. We've got to be prepared for member absences, which means we've got to be able to hand off apps (temporarily or permanently) if necessary.
I think we should work from oldest to newest. There's a lot of apps on the release queue that have been waiting for pretty near forever, and I don't think it's fair to let some apps queue-jump because they're more popular. Besides, popularity is a very subjective concept.
Speaking of imbalance in the app list, we also need some organized system of contacting freeware developers to get their permission to portabilize their apps. For example, I contacted Paul Freshney about portabilizing his great Periodic Table Viewer, but he turned me down flat. We need a way to pass things like that to somebody the dev (Mr. Freshney, in this case) might actually listen to.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
I guess this isn't release team specific, but what are we going to do with apps on the test page that we just aren't ever going to make portable due to whatever circumstances and haven't been in development for a long time (e.g. Nexuiz)?
Leave them there or remove them?
I'm looking back at existing comments, and I'm seeing one common thread (no pun intended): everybody wants (needs) flexibility. People need the flexibility to leave if necessary, the flexibility to hand off an app if necessary, the flexibility to take on more apps if desired/necessary.
Where the wind is regularly very strong, buildings are built flexibly so they can sway in the wind instead of resisting the wind and eventually breaking. IMHO, this is a good analogy for what we're trying to build, and the lesson - be flexible - is as important in creating a release team as it is in creating a building.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
There will be no ranking system initially. Perhaps months from now when we have the time to implement it into the site. The tools available are:
- email list via SourceForge (limited to release ream members, records are public)
- forums here on PortableApps.com
- wiki-esque testing page with all release team members able to update it, add notes, say what is tested and what failed, etc
Those are the sole tools we will have at our disposal for now.
Sometimes, the impossible can become possible, if you're awesome!
A ranking system would just be asking for drama, as I see it.
A ranking system shouldn't cause any trouble - it hasn't on TPFC - but you might be right. People can be a bit unpredictable with things like that.
Steve Lamerton's objection was valid, too; there's a number of people who would end up with a low rank they don't deserve.
Well, I guess that ends that, especially since we don't even have the ability to implement such a system right now.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
How is the work going to be split up
Your idea right now calls for only 2 groups of 3. Let's extend that. Each group of 3 should be assigned a goal. Maybe OS compatibility testing, Code testing, Portability testing, etc.
How much responsibility and power should the head have
The lead should check around the forums and see what needs to be done, and assign groups jobs, then find out what apps are ready to be official.
When is it right to move an app between stages
Well, let's just move it when each group submits positive results, and has tested it (unless it's OS testing).
I think that the comments above are almost all assuming too much structure and time. If the release team were regular nine-to-five employees of Rare Ideas, LLC, the plan would work fine; as it is, I don't think that it will work that way. We need to have a more informal structure but with more reporting. Also due to the probable slight irregularity of availability of team members, I think a larger team size would be appropriate.
I'm not yet entirely decided as to how work should be distributed; it could be app-centric (X Portable, Y Portable, Z Portable) or it could be task-centric (portability, format compliance, base application quality), or some other basis I haven't thought of yet.
I think it could be useful to have a selection committee as part of it, selecting applications that should be tested. Not a voting panel, but rather a small team that selects which programs would be good to push through - generally with the basis that we are trying to cover all categories, and select high-quality applications. I think it could be good to start this team up before starting the actual testing teams up. If they have something to get into right away they'll be more likely to do work when it's available, I think.
I've still got more thoughts but no time to put them down now.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Yep, I totally agree. As I mentioned earlier, though, we'd better plan for more than just "slight irregularity"; Murphy's Law applies here, and we'd better have a way to keep going anyway.
* Release sub-teams: we should probably have at least one sub-team on standby, just in case.
* App-approving process: we need to make sure that, no matter how the final process is implemented, there's at least three people who can get an app officially released. Relying on just one person is a disaster waiting to happen, IMHO.
I favor app-centric. It's probably a bit smoother than task-centric, since there's no "our group finished, but the next isn't ready, so now we wait". It also gives people some variety as well.
I disagree. While that would let us release some popular apps, it would also leave a lot of old ones in the release queue; I don't think that's fair to those devs. That would also leave some devs with the impression that "my app just isn't important", and that's the kind of thing that makes people quit.
Just my 2¢...
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
am going to bump this topic because I think we need to get this sorted, all we have decided so far is that we all think different things!
and that's pretty much why the original team died, no one could agree on anything
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
I'd rather not dictate, but I can set the ground rules of the utilities we have available which will define some boundaries (as mentioned above: public forums, private forums, private email list with public archives, pre-defined wiki-style pages for group editing, etc). We may be able to add to this list later, but not right now.
I think the initial commitment of 3 months works. The idea of multiple teams has some merit, but will require more individual commitment and leave more up to the failing of one person. Requiring members to do at least one app review a week is a good baseline.
Sometimes, the impossible can become possible, if you're awesome!
For instance, Chris and I (and possibly others) are taking classes which have priority, so even setting it to one app every other week would lessen the stress quite a bit. If there are two sub-teams like Steve posed, the overall production line can still maintain one app a week; one team would release a given week, then the other team would release the next, and so on.
Most of our developers are at school or Uni. And most of our developers (and users) tend to stay a while and then drift on again. That's the way our field is. John is the exception, he's positively old
I think that an "N per week" is reasonable as a requested level; I don't think having two sub-teams would help at all initially but rather end up with time-zone delays (and I'm-busy-working-on-an-assignment delays) becoming more troublesome.
I'm also thinking I might set up a quick Pinax-based system for powering it; I can think of various additions that would be useful in it and even the basic stuff Pinax provides could be very useful. And now that my website is hosted with WebFaction I can very easily set it up. I think that a basic RT system made out of that could increase productivity (especially in communications) enough to justify some work on it.
I agree with Oliver, we need structure and direction so that we know what we're doing. It probably wouldn't hurt writing a 10-page (or maybe not quite that much) specification document.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
I think defining a spec page would probably be the easiest and quickest way to get this going. Say John (or whoever) puts down all his ideas for the RT in an organized document, and then like a project the developers can propose changes until it's most agreeable to those who wish to be apart of the RT.
Please set some baselines. The RT team can argue about whether or not they are still needed. But structure and some direction is needed.
Too many lonely hearts in the real world
Too many bridges you can burn
Too many tables you can't turn
Don't wanna live my life in the real world
is ok. I say its ok because you're on a team. that means you don't have to do it all. And if you cant invest a lot of time for like a month, others do a little more and things are compensated. So I don't have to feel bad just because I go on vacation in the Bahamas with my girlfriend for one month
Couple ideas:
I think all the things John mentioned are sufficient for now (its enough to get started and see what else we need). I guess they can be set up here so there is no need for a separate website/login. It might be useful to have something different like Chris suggested but I remember Ryan doing that and I think there is a lot of possibly useful stuff on his pages no one uses anymore because we forgot or dont have the time to go over there when we need it.
Just a couple Ideas that came thru my mind in the last 10 min
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
The leader of the Release Team needs to be called the Panjandrum.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
How does this sound? I think it takes almost everybody's viewpoint into account, and hopefully everybody will be happy with it.
* We have a webpage where the team leader(s) list tasks for the team members to do
* Each RT member, when they have time, checks the webpage to see what needs doing, then edits the webpage and puts a comment next to the job they want saying [Taken by (username)]. For example, if John puts up "Portabilize Opera", and I take that job, the task would look like * Portabilize Opera [Taken by computerfreaker]
This would take the "one app per week" pressure off, as things don't get much more flexible than this. It means people can come and go without needing to worry about the repercussions - as long as they remember to #1 put their name next to jobs they take, #2 check off jobs they finish, and #3 take their names off jobs they realize they can't do for whatever reason.
* Each of the team leaders would be called a Panjandrum, to please Chris
I know that's a very simple plan, but I think that's all we really need. Think about it: it pleases those who want one app per week, because they get that. It pleases those who need flexibility, because they get that. It pleases those hyperactive lunatics (myself included
) who would cheerfully take one app a day if time permits. It pleases those who don't want to wade through a mountain of documentation on how Things Must Be Done The Right Way. And last but not least, it pleases Chris and his unusual vocabulary 
Thoughts?
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
pretty good to me. We might need to say that two people claim each task (one after the other) to try and reduce mistakes though.
and I agree with Steve. Having 2 people for each job adds an additional pair of eyes with never hurts
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
Nearly all the jobs will be slightly less sexy than "Portablize Opera" for a while. The release team is about testing for the near future, which means testing all the backlog of development tests for actual release. We have over 100 apps to get through. We have plenty of developers and app packagers. The "Release Team" is about formalizing testing and release practices.
Sometimes, the impossible can become possible, if you're awesome!
Yeah, "Portabilize Opera" was just an example. I know the RT is more about taking already-portabilized apps and making sure they're truly portable, PA.c standards-compliant, etc.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
I'm proposing that we come up with "a mountain of documentation on how (sic.) Things Must Be Done The Right Way" because I think it'll help to:
Think of it as an ISO 9000 quality management system. Of itself I don't think it will be very useful (except a severely pruned checklist for members after they've read it once at the start and whenever revisions are made) but I think the process of generating it will be very useful.
As for managing a what people should do, I think a Pinax solution is a far better solution than a separate page; for an example of the included tracker application, see code.pinaxproject.com/tasks. I was able to set up my own Pinax site very quickly; here's the task tracker in it as it currently is. It's a very rough job, and there's a lot of refinement still to go with it (the theme is fairly ugly, and the templates could do with some improvement too).
If we're going to have sub-teams, we need to either
think up a new name for the sub-team-leaders (I prefer this plan but it requires more thought, I don't have any similar ones handy in my vocabulary at the moment), or (b) have team (Team?) Panjandra and then the Grand Panjandrum in total charge.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
going to work with an off-site solution, I know the last time I talked to John about it, with regards to a decent program translation system and bug tracer, anything off-site or that we couldn't host here was a no.
I agree with the need for documentation, but for the level of detail you seem to want I fear you are the only person willing to do it, and presumably your time is already pretty busy with the other stuff you are doing on the site right now? I am now pretty fully committed with Google's Summer of Code and my end of year exams, as well as trying to get Toucan 3 finished up and released, does anyone else have the time? Otherwise I think we would have to move to a document as we go along solution and accept that the first few people involved are going to have to do a lot of 'admin' stuff too.
I vote in favour of keeping it here. It might lack some features but its easier to maintain and I don't have to log in twice
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
I quite agree with you; integration and hosting at PortableApps.com is something I want to achieve. Partly for this and partly for my own purposes I intend to write an authentication application for Django so that it can use the Drupal authentication table, and if I can manage it, the cookies too. (That part will be harder.) Doing that will take longer than using the standard Django authentication application, but it's quite possible.
The other option for obtaining a similar system would be CCK and Views based. I could work on a prototype for that as well. It would be more rapid to build and would provide more complete integration (especially the slightly-clunky feel of having to load a new page to post a comment or reply to a comment rather than using nice Ajaxy goodness ;-)); but it wouldn't be as powerful.
I think we need to at least make a list of things we do and write something before we start; it doesn't need to be a 30-page document but I do think it needs to cover what we're going to do. Otherwise it will founder from the start due to not knowing quite what is needed. What we need from such a document is mainly organisation. Innovation and improvements in procedure can take a secondary place if we don't collectively have enough time for it, but organisation is mission-critical.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
@Chris - I agree.
Get all the information in one place, so you can see the whole system at a glance.
Some thoughts based on my past experiences:
Finding the starting point is always difficult, if you are trying to take a formerly ad hoc process and develop some structure.
When I've done this at work, I've used two different approaches to kick-starting process mapping.
1. The Post-it Note system. Usually done IRL in a meeting. Everyone who has been doing things there own way gets together and writes each individual step of their process on a post-it. The post-its are then arranged on a wall, grouping like steps together, to get an overall idea of the process. Extraneous steps become obvious; likewise, steps that everyone uses are likely indispensable.
This also involves a lot of live realtime discussion of the steps and pizza.
Since it is impractical to get everyone physically together, you'd need to do an online conference. I've just started playing with an open source one at openmeetings.de, it looks pretty powerful, but I haven't used it with others yet.
2. The Mind map system. Works well with a single very knowledgeable person and lots of others with input. I use Freemind to do a brainspill, and then start dragging the bits and pieces around to make sense. Then, I share this with the others in the project, who comment and add their own ideas, or vote down inefficient ideas, until we come to a consensus.
The three key parts of these approaches are:
(B) Collaborate with people to get the best practices
(C) In the end, simplify the process to a list of indispensable common steps.
The forums here are not able to achieve
as they are configured. Collaboration (B) here does happen, but what with multiple posts and replies and branches of replies, information tends to get very fragmented. Ultimately the tools to maintain the system should be hosted here, of course, but the initial organizational collaboration should take advantage of existing tools like openmeetings, or even TeamViewer and Skype.
I know, it sounds like a lot of work in the beginning, but it is better to do the organizational work up front. Not only does it make the subsequent work more efficient, it's a real service to the release team to have clear guidelines, so that they don't waste their time.
I made this half-pony, half-monkey monster to please you.
Yes, mountains of paperwork can be very helpful, but I think a couple of pages will suffice. The PortableApps.com Format Specification, for example, is only 5 or 6 pages long but has enough information for anybody's needs. We don't want to chase off newer team members who may not be in the mood for an hour or three of reading.
A checklist would be great, but IMHO it wouldn't need to be huge. I don't visualize such a checklist getting beyond three pages.
As for the naming of the team & sub-team leaders, I defer to you on all counts.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
the idea is NOT to end up with mountains of paperwork.
Step (C) says that we end up with a (SHORT) list of indispensable steps.
The problem is that we need consensus on what the final list will be. And for that, whether we like it or not, it will take an initial amount of collaborative work to harmonize the best practices.
As my old boss used to say, you can pay me now or you can pay me later.
There's no substitute for good solid planning to make everything that follows easier.
A really good example is this new 2.0 Format, Installer, Launcher, etc. By all accounts, it is a lot of work, and seems to be taking forEVER, but in the end all that smart planning will pay off big time.
I made this half-pony, half-monkey monster to please you.
I did read your post, and IMHO we were talking about different aspects of things. I was talking about a basic idea ("let's not have too much paperwork"), and you were proposing some concrete ideas for organization (which indirectly includes the idea of "not too much paperwork").
And yeah, good solid planning is necessary. That why we got this thread started. Unfortunately, it seemed to be mostly dead, so I decided to bump it a bit by replying to a couple of comments.
2.0 will definitely help us get the RT off the ground, but I don't think our planning & discussion is complete. Until it is, we could get to 25.0 and it wouldn't make much difference.
So, who wants to draw up a tentative checklist? I'm willing to take a shot at it, but I'm not exactly the best writer.
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
It's sometimes hard to tell in these threads whom you are responding to. Once I put my finger on the screen and scrolled up to see who your post aligned with, I could see you were responding to Chris.
My mistake!
I made this half-pony, half-monkey monster to please you.