[isf-wifidog] Re: [isf-vol] Nouvelle mise à jour de wifidog sur le serveur

[Benoit Grégoire]

> Best of all from my point of view, the stuff that helps us move
> forward with the portal page / content side of ISF.

The most significant part (I think) is one you didn't highlight:  the 
ContentReport, that finally allows us to measure how much people do/don't  
interact with the various content we provide.
 
> You mention metadata for content being replaced by "something better",
> "best practices" for showing sponsor information, and editing the flow
> for content management.   I know that you have loads of expertise in
> educational metadata and that you're busy, but I think it's important
> to again request for some way that myself, ISF in general or other
> people that work with online curating/exhibition, could give feedback
> on these features before they are developed. 

There are various ways of giving feedback (verbally at meetings and 
conferences, as tickets on the wifidog trac, on IRC or on the wifidog mailing 
list).  

We frequently ask for it, but seldom get it.  When we do, it does often 
results in actual changes.  In fact, all the examples you listed are the 
direct result of feedback from organizations using wifidog:
- Getting rid of the sponsor field comes from the St-Louis conference.  
- "Is artistic" and "Is locative" were removed because of a general concensus 
that ways must be found to de-clutter the content manager admin interface and 
because they will be made redundant by whatever content grouping evolves into 
(and guess who's pushing on that ;).
- Changing the flow of the editing interface was done after feedback from 
U2Com (a UK company that uses wifidog).

But people rarely notice that a specific change is the direct or indirect 
result of their feedback,  unless the feedback was through a ticket (the 
ticket will be closed when the change gets in, and the person will get an 
automated email).   So some people are left with the strange impression that 
the process isn't open to everyone.

Off course, the developers cannot agree with every suggestion.  Sometimes 
because they simply disagree (it does happen, but usually a compromise is 
reached), but generally because implementing the suggestion would have 
negative consequences on other parts of the system or difficulties/costs the 
person who made it didn't/couldn't know about.

> For example, how will it 
> be decided which metadata should be available for content pieces?

The short answer is the editor/curator of the different group should decide.

The very segmented metadata (Title, Description, long description, project 
info, sponsor, author, locative, artistic) for the content manager came from 
the very structured way we thought content would be curated back in the days 
of our collaboration with MDCN 1.

Every piece of content displayed on the portal was meant to have the same 
structure, and have visual similarity no matter it's nature (image, text, 
feed, video, etc.):  a large area for the actual content, with the metadata 
around it.  That way the user could at a glance figure out where the content 
comes from, if it's artistic, locative in nature, who the author is, etc.

The "unit of interest" was supposed to be the content pieces, taken 
individually, not the portal as a whole.  so far that didn't work out too 
well because:
-Few portals actually have large number of content pieces displayed at the 
same time, so we have no significant userbase to give practical feedback on 
these issues.  Most simply do not yet encounter the problems that this 
systems was meant to solve (content organization, consistent UI, distributed 
curation).  And when you have a portal with little content, it is perfectly 
rational to be less willing to compromise on aesthetics to get better content 
organization. 
-These fields were meant to be labeled in the end-user UI.    The labeling was 
removed early on for aesthetic reasons (I bowed to the pressure, which may or 
may not be a good thing).  As such, most people using the content manager do 
not care what the fields are for, just how they are displayed. I would love 
to label them again, but I am under the impression that most people would 
oppose it still (But, maybe I'm assuming too much about other people's 
opinion).
-Having a very structured form for metadata is no substitute for a proper (and 
ideally enforced) editorial policy about metadata.  
-We underestimated the huge headaches that groups of small units of content 
(some RSS feeds, events and the like) would cause.  They currently break most 
ways we could otherwise groups content.

Deciding to get rid of the sponsor field was an easy decision:  sponsors 
information actually IS project information.  If a group chooses to display 
this info, having it in it's own field adds little (actually, it adds nothing 
as long as the field's aren't labeled).

> I'm 
> sure that there are several of us that would like to be involved in
> these decisions, from NYCwireless, WT and ISF, and perhaps elsewhere.
> I'm not saying it's your responsibility to make sure those discussions
> take place (if anything, it would be Francois's job if he weren't knee
> deep in stuff at MIT).  

Indeed.  Feedback is solicited on a fairly regular basis, and rarely obtained 
(even from ISF).  But the "decision" process is most definitely open.  In 
fact so far we only refused a single patch:  automatic node creation for 
everyone.  It was only refused until access control could be built into the 
patch and the feature could be turned off for groups that didn't want it. 

Unfortunately, not many people are willing to take the time required to give 
constructive criticism on how the current system should evolve (rather than 
we should start over with buzzword of the day, but they have no time to 
help).  Yet a lot of people are very eager to criticize features of wifidog 
(sometimes very publically) when they don't do exactly what they want.  Once 
you start improving what they complain about, they frequently still won't use 
it/comment on it.

But that is not unique to wifidog, nor to open source development.

-- 
Benoit Grégoire
http://benoitg.coeus.ca/