Add Repository Information

[undecoded-coder]

The GitHub repo may seem a lot more inviting to potential contributors if it had more information available, especially a ReadMe file.

Specifically, it could be beneficial to include some of the following information:

• This is the current (official) development repository
• It is still alive (hopefully for a while yet)!
• Contributions are welcome
• Any contribution guidelines or suggestions
• Pending tasks someone could help with (Migrate to ARC, move to Metal, etc.)
• Current project maintainer(s)
• Original author (Allen)

Additionally, information could be added to the repository metadata:

• Webpage link
• Relevant GitHub tags
• More informative description

(See added metadata in my fork for example).

cc @bsupnik, @allenmonroesmith

[d029940]

This a good idea. Myself I am working on ARC. There are some files (e.g. which uses 'unions' which needs to rewritten or we must give up some optimisations).
My problem: I 'm not very firm with GitHub.
Just mentioning what I did:

1. In the project file (Compile resources ) I flagged every file with '-fno-objc-arc'.
2. Convert the whole project to ARC => Every new objc-file will now be under control of ARC. But in combination with '-fno-objc-arc' for all existing sources, nothing really changed.
3. Started to remove the '-fno-objc-arc' flag already for some files while changing the source to ARC (removing autoreleases, retain, destructors (if they only manage memory), etc. This the time-consuming task.

Testing is also very time consuming, because in the end nothing changes to the user. It's all only technical.

[undecoded-coder]

I am primarily trying to update the UI components (and hopefully make them easier to maintain going forward) as that is what I am most familiar with (I’m still not comfortable enough to help out with memory management though, coming from Swift!).

[undecoded-coder]

Myself I am working on ARC.

I would suggest creating an Issue to keep track of ARC migration. It may also be a good idea to create a public branch with the changes so anyone else who wants to work on it can see it or contribute, look for any issues, and keep it up to date with the master branch.

I'm not sure if a non-maintainer can create a branch on the base repository though, so you may need to publish the branch to a fork and submit a PR to add the branch upstream (and then successive PRs for later changes to the branch).