Hi, I wrote this *short* checkboxes list on the registration page, because when something like the "How to Get Your Project Approved Quickly" wiki page is too long. (Before the checklist there was a multi-step procedure with a brief explanation of our hosting requirements, and a lot of people didn't read it already.)
I agree that we can make the link clearer and more inviting - check the register2/ directory in savane-cleanup.git. I don't think it will help to make a single list on a separate page, people won't click on the link (just like we don't ready TOS when registering an account somewhere else). Maybe I don't see the advantage over the checkboxes list. I agree we can stress that the hosting requirements are firm, and need to be taken of prior to approval. I disagree mentioning "or be prepared to wait some weeks" because even people who comply with the requirements wait for months in the current state of things. -- Sylvain On Fri, Aug 28, 2009 at 09:15:31AM +0200, Sebastian Gerhardt wrote: > Hi Nicodemo, > > I agree, it's currently frustrating both for the admins (pointing out > same issues again and again) and the users (waiting very long and don't > know why). > > I am going to compile a page where all our customary > requirements are listed in one single list. Then we can remove the > other checkboxes on the register page and accentuate that single link. > > My suggestion is to get the following message somehow across to the > applicant on the register page (not literally): > "Your project will not be approved until all requirements applicable on > this list are met. So you had better spent the 5 minutes to check it or > be prepared to wait some weeks." > > > Sebastian > > > On Thu, 2009-08-27 at 17:47 -0500, Nicodemo Alvaro wrote: > > With the large amount of submissions not complying on first try, maybe > > it would be better to make it more evident that the "See *Wiki*" link > > the registration page could say "How to Get Your Project Approved > > Quickly" to make it more inviting. > > > > I was having a discussion with the OpenVRML applicant on how come we > > do not allow "open" in the name.
