Affero Update + Documentation

Okay so lets get this post in order. As the title suggests the update on the project will come first and the documentation after. First though I would like to get a quick piece of feedback from your good selves.

I am trying to maintain this blog a lot better this year as I look back and discover that I have done a lot that has gone undocumented, so, with that in mind, I ask you. Should I continue my two posts a day rule? Or cut it down to just the one post? You can answer this question here on this small form or in the comments at the end of this post.

Affero Update

Okay so I finally worked out why my test site was playing up (a bad .htaccess file was the cause) and I have now fixed that so I will not be going through the aggravation of moving Affero to another server.

ChangeLog:

• updated the DAL testcase to work with new test data in the database
• modified the .htaccess file to fix the odd few bugs I was getting on the development site
• updated the utilities test case to work on most domains (where Affero is in the root dir or a directory named affero just off root)
• wrote some tests for the user management class and as such started said class (currently passes all tests)
• updated the documentation (should go live about midnight) [correction… fought with phpdoc to document the code]
• completely removed the blog from the project dir

Affero Documentation (Feasibility Analysis)

Mozilla have already come up with multiple solutions which all work in tandem with each other. Not all are computer based. So, is the solution to the overall problem that this project aims to tackle, feasible for a computer based solution, or would it be better suited to a non-computer based solution?

The first step to getting the answer is to define what type of problems computers are good and bad at, and how these things tie into the problem. Next we should also define what people are good and bad at, and how these tie into the problem. Once this is done it will be possible weigh up both options and choose an avenue to continue researching with the aim of providing Mozilla a solution to their problem.

What are computers good/bad at and how does this relate to the problem?

Computers are very good at solving problems which require a large amount of constant, and/or, repetitive tasks. This is great as the system is likely to need to work with a large number of inquiries on a regular basis. Some of these tasks are also likely to involve gathering and processing of metrics. This processing, provided it is always going to be the same, can be easily automated thus saving time overall.

Computers are also good at communicating with each other over extreme distances thanks to the Internet. They can communicate in real time with little in the way of issues provided they are using the same protocols. This is relevant as whatever solution is used it will need to be globally accessible. Computers are not so good at working with people and giving them advice. This could be an issue when the problem itself requires advice to be given.

Computers are not good at making decisions either, especially when it depends on personal interest. Again something that will be needed to help solve this problem as any possible solution will likely have to interact with the user and judge (decide) what the best advice (oops, another problem noted above) to give to the user.

What are people good/bad at and how does this relate to the problem?

People, unlike computers are bad at processing large amounts of information. They get bored of repetitive tasks. This leads to them making mistakes, and generally taking longer due to making corrections, and the need for sleep, food, toiletries, etc… This could be an issue when trying to solve the problem as people also like to get quick responses. If the responses are not swift then the end user making an enquiry may not join the community, and as we have established in the problem definition, this is not good for Mozilla.

People are also not very good at global communication. I the current day and age in which we live, it is common to utilize the Internet (via computers), to communicate globally. This can be done using email, IRC, VoIP, etc… Which allow for the
breakdown of the distance, and in some cases the time and language barriers. People can communicate over large distances without the aid of computers using what is now commonly referred to as “snail mail” or to be more specific, pen and paper, then posting it to the required destination. This can take a lot of time and can be unreliable as there are lots of opportunities for the letters to get lost. It also cost a lot when sending large quantities of responses to enquires as this method will cost per letter.

People are good however, at giving advice. It is something we often do without realizing it. Advice is something people are good at as they can tailor it to the individual they are advising. If they person being advised does not understand completely they can respond with questions and get answers back. This could be very important in solving the problem at hand, as it means that the relevant information can be given to the right people wanting to get involved with Mozilla.

Feasible plan of action

After looking at what each possibility (computer v person and paper based solution). It is clear that any solution put into play will have to use a combination of the two approaches. It is vital that global communication with quick responses where possible, is in use. This can only be done by using a computer based solution, however advice and decision making must also be used to solve this problem.

Therefore the appropriate course of action is to research current solutions to similar problems that utilize the strengths of both computers and humans alike.

Okay so this goes a little in depth about somethings that would seem obvious to most of us however you do need to remember that this project is not only to show technical competence but also to show a thorough understanding of the types of problems that computers are good at solving and why.