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 <[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]
