In general, treat the projects as jobs. On the resume, create a section for personal projects, and include:
- Name of project or software product
- Organization (if applicable) that the project was for
- Description of the project and your work on it.
- time range of contribution
- Any reference you can provide to it - URL, github respository - what ever options you can give to let a reviewer access it.
As a resume reader, I don't generally look for examples of the work when we're talking about paid-for job - because I realize that so much of a person's work may not be publicly available. I have, however, googled for the company to see what the business is about.
But personal projects are both under the applicant's control, and also wildly variable. So if I think of the project as a great example of good work, I actually go and look at what I can. Which means that good code, either in execution (like when I visit the MUD) or in a repository, will leave a good impression. And bad code will leave a negative impression.
My strongest recommendation is - don't share a work in progress that will leave a poor impression. For example, getting a tech writing sample from a writer with poor/inconsistent layout, bad grammar, and bugs in the HTML will be worse than no sample at all. Same goes for code - if your website is buggy, if your code is a horror to read, etc... I'm going to be concerned about your judgement.