>>>>> "Jim" == Jim Walker <[email protected]> writes:
Jim> I assumed the db would be reloaded just prior to the actual Jim> transition. Prior to use, it's easy to reload the table and try out Jim> new schemes. Once you turn it loose and people start updating Jim> elements from all directions it gets harder fast. Well, once the database is being used in production, some downtime might be needed to complete a migration from one schema to another. But there are ways to minimize the downtime (e.g., doing the transfer incrementally), and there are already plans in place for occasional downtime for routine maintenance (i.e., totally unrelated to the migration). I'd expect that any schema changes could be completed during one of those downtime windows. IIUC, one of the advantages of the current approach is that the schema and associates semantics are pretty straightforward, with not a lot of ways to get creative. So I don't see a migration to a new schema being that challenging (though I concede this isn't my area of expertise). Also, to get a benefit from trying new schemes, you have to have a sufficient number of people actually using the new stuff and giving feedback. My understanding is that there hasn't been much usage or feedback of the current test (hub.os.o) site, so I'm skeptical that delaying the migration would actually buy us anything. Mike> Are you concerned about a community backlash if people get write Mike> access due to the migration, and then lose it again as a result of Mike> decoupling permissions from governance status? Jim> Yes. For example, if I'm a leader of a large community, project or Jim> user group and spend time setting users up and get familiar with Jim> the terminology and then it changes or I have to do it all over Jim> again, I may be upset. And, I think even within the first 24 hours, Jim> many if not most collective leaders will setup users as they see Jim> fit. With the current plan, at the community level there's not much for them to set up. If there's someone who needs editing privileges and doesn't have them, the community will need to grant that person Contributor status. But in that case the community probably should have given that person Contributor status anyway. At the project level, anyone who has commit rights and is not a leader (for the project) will be automatically given Developer status[1]. I suppose some tweaking might be needed, but I'm having a hard time seeing this as a big deal. I'm not wild about the term "Developer" for the reasons you've given in previous mail, but I also think someone (Laurent? Peter?) had a reasonable point about how the term "Contributor" can get overloaded and confusing. mike Footnotes: [1] http://opensolaris.org/os/community/web/transition-data-migration/ _______________________________________________ website-discuss mailing list [email protected]
