Hi Jim, I have filed two RFEs for the two issues that seem to have some merit, as follows:
This first one is filed against the auth webapp for an exception list related to the concern about Contributor status being for life. http://defect.opensolaris.org/bz/show_bug.cgi?id=10063 I personally don't think we're going to need it because I've never had to remove Leader privs for any user in the past, but it has merit as an enhancement if we do need it. In addition to having a very easy way to rollback changes as Mike Kupfer described, Xwiki also enables us to 'watch' pages and entire spaces, so we'll get notification of every content change as soon as it happens. I believe this will very effectively cover Valerie's concern. To Rich Lowe's point, we also have the ability to annotate pages with Xwiki. So, if users want to make comments on pages, they need not have a governance role. Let me know if I'm missing something Valerie and Rich, I appreciate your feedback. This second bug is an OGB bug (that could very well be a duplicate, but I'm not sure) against the Constitution for a separate, new role called Member that includes only the voting right. I believe I've correctly stated in the bug description that the auth app already has the data structures in place (via the electorate collective) and we just need to get the member role defined and approved in the new Constitution. Jim Gris, let me know if I've mis-characterized things in the description of this bug. http://defect.opensolaris.org/bz/show_bug.cgi?id=10062 Unfortunately, Vincent is having offsite next week that likely prevents folks from attending our OGB meeting, but I will invite Bonnie and Jim Grisanzio just in case. I didn't file RFEs for your terminology comments, JimW, so feel free to do so using the same auth webapp category and the team will address them as time permits. Regards, Michelle Jim Walker wrote: > Michelle, > > Can you arrange for some of the os.o team to > meet with the OGB mext meeting? > > We are circling in email, and these topics > impact the entire os community. > > Cheers, > Jim > > Mike Kupfer wrote: >>>>>>> "Jim" == Jim Walker <James.Walker at Sun.COM> 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/ >> >
