I suggest to leave the registration discussion for the conference call. The differences between the terms we use are very subtile so I guess by voice we will find a sticky agreement that can be slippery if handled by email. For instance, I don't see the differences between 'creating and account' and 'registering', and I was only suggesting 'shopping cart' if people would buy merchandising items, not for the event registration. In general, I recommend we use the conference calls to deal with those topics that resist to email consensus. For practical (and sometimes confidentia) reasons, conference calls are restricted to guadec-planning. If you are not in that private list you can send your comments here and they will be considered in he meeting as well. Thank you. En/na Fernando San Martín Woerner ha escrit: > users don't > need to create an account for get a registration, just to fill a form > with their data and payment info. Last year were a lot of complaints > about creating an account. I guess the complaints were that first you had to 'create an account' in the website and then 'register to GUADEC'. This is a usability issue thoug, since creating an account requires only an id (a name) and an email, and you are already requesting these fields in your 'proposal of registration'. This is why I think we are talking at the very end about the same thing. > i didn't work on this yey, my main concern is how tomigrate encripted > password to new system and as i sasy below if we need to use password in > a new system. My suggestion is: forget about previous users and start from scratch, so all the users can decide whether they want to be registered / have an account or not. In fact, people may well accuse us of spam-alike activities for reusing their data without permission in something different than GUADEC-Stuttgart. We can use the current list of users ONLY to send an announcement of the new website once we have a v1.0, inviting them to join us this year as well. >>>* Setup the store with test products, my main concern here is to avoid >>>the shopping cart, wich was very confusing for some. >> >>Drupal's shopping cart is very standard: select items, check out, pay. > > > > but we want to avoid shopping cart Agreed, we were talking abut different context/purposes. > this is a must, well done! No answers received by now. :) Anyway, we can start with transfer / credit card / paypal and when we get a complaint we ask for the desired alternative and, if feasible, we implement it. Dave wrote: > We should also bear in mind, from the start, two categories which won't pay - press (who should have a way to apply for press accreditation) and speakers (who have paid for the last two years in GUADEC, but I would like to modify that). With database magic this shouldn't be a problem. There is a eCommerce module patch out there that allows to process 'zero payments'. We will only need to confirm manually that they are right - as we will need to do with other sponsored assistants, students, and so on. All this makes me think that all the extra hacks we develop shpuld take in account the CiviCRM module Luis was suggesting (and still he suggests these days as a candidate for reelection). Because I think during this year we are going to use it (as practically decided) and because GUADEC is one our main sources of contacts. See http://www.openngo.org/ to get da feelin'. More about this in our conference meeting. -- Quim Gil - http://desdeamericaconamor.org
Attachment:
signature.asc
Description: OpenPGP digital signature