quality control

4 views
Skip to first unread message

Michiel de Jong

unread,
Jul 20, 2011, 5:46:51 AM7/20/11
to unhosted
Hi,

I always ask people 'if the unhosted project were to fail, what would most likely be the reason?'. Most people say 'lack of freemium providers'. I myself am not so worried about that one, I always think getting people to develop apps that allow unhosted accounts is the biggest challenge, with on the second place probably creating a way for end users to understand where they can use their unhosted account (a recognizable 'green logo' or whatever).

but a friend of mine, whose opinion i highly respect, said the biggest challenge would be matching the quality of commercial apps in apps that are provided as-is. I now realised that we need a strict separation between a staging environment, where we can try stuff out, and a public environment, where others can see what we've been working on. And the public environment should only display stuff that works, not stuff that is being worked on. I'm looking for a way to not let stuff like http://twitter.com/#!/pfinette/status/93522368911245312 happen again.

So I moved the syncStorage demo to http://dogfood.unhosted.org/syncStorage/ to indicate that fact that it's still under development. I put https://myfavouritesandwich.org/ back to the 'devel' branch. Looking at it again, I also realised that even the devel branch is far from good enough to be shown publicly. it has error alerts that are good enough for us when we're testing, but it would be unthinkable that they would appear in a commercial product.

So that's my new idea: doing actual quality control, and only publishing things that have a quality level that you would expect in a commercial product.

I have to think about how we can do the same for the source code. i want to regularly push bits of code that are unfinished, but then there should be clear branch names that indicate what is for use inside the project, and what is for more stable.

I also registered syncstorage.org as a domain name in which we can publish info about syncStorage, for web developers who want to write web apps that can be used with unhosted accounts. So the organization could be more or less:

unhosted.org, www.unhosted.org: production, general info
syncstorage.org: production, for web devs
myfavouritesandwich.org: production, for end users (see below)
dogfood.unhosted.org: staging, for internal use

I want to also offer test accounts @myfavouritesandwich.org. the silly domain name will make clear that these are just for testing purposes, yet at the same time it gives end users a way to easily try stuff out.

we should then also think of a way to publish which web apps we recommend end-users to use with their unhosted accounts, and a longer list of web apps we know are being worked on, that we recommend enthusiasts within the project to check out (but are not ready yet for end-users to use).

If we have this clear distinction between staging and production, it will be easier to share stuff openly (which I think is super important), while leaving clear that it's not ready for end-users yet. Suggestions/comments welcome. :)


Cheers!
Michiel

Edokoa

unread,
Jul 20, 2011, 8:51:14 AM7/20/11
to unho...@googlegroups.com, unhosted
I'm glad you finally took this decision. I agree completely.

Sent from my iPhone

Michiel de Jong

unread,
Jul 20, 2011, 9:59:30 AM7/20/11
to unho...@googlegroups.com
Hola Javi!

On Wed, Jul 20, 2011 at 2:51 PM, Edokoa <he...@edokoa.com> wrote:
I'm glad you finally took this decision. I agree completely.

I'm glad you agree :) Don't worry though, I will still publish stuff that is broken!! ;) I will just clearly mark it as 'this is a flaky work in progress, for open discussion, not ready to use yet'.

The discussion you and I often had is whether we should do one or the other: Incrementally do things that only half work, or set out to do something that's solidly designed from start to finish. I am still a strong believer in the incremental model, and in public discussion of draft versions that are not ready to use yet.

But now that we're apparently starting to get more visibility, I think we should be doing both types of output, just take good care to clearly mark each one as either 'public' or 'work in progress'.


Cheers,
Michiel
Reply all
Reply to author
Forward
0 new messages