Re: [Libreplanet-dev] LibrePlanet development

[Peter]

On Thursday 06 August 2009 21:43, you wrote:
> Peter <address@hidden> writes:
> > Hi all,
> >
> > I'd like to thank those people that have assisted me in working here, but
> > I see my contributions are no longer welcome.
> >
> > After specifically setting up the LibrePlanet group for the FSF, I see
> > they have created their own group. The templates I created, were first
> > tampered with and then deleted as 'old' and 'broken'.
> >
> > The frustration for me is that the website is now setup to implement a
> > form based wiki. Since I have been kept out the development loop, there
> > is no way I can contribute productively.
> >
> > I will support my extensions, but I don't expect they will be used ;)
>
> I'm sorry to hear that Peter. I don't exactly understand what you mean
> about the FSF group -- what I did was consolidate the multiple pages on
> to one, because at that time we had an immediate use for it (posting our
> meeting minutes and a link to them). I put this group in the Group:
> namespace, thinking that I was following the plan that you'd been
> suggesting. To me the LibrePlanet group is different from the FSF group.

I understand what you did and agree with your reasoning. I am assuming the FSF 
has designated specific staff to run the LibrePlanet. If so, these 
individuals form the LibrePlanet group, with designated wiki positions 
(curator, administrator, bureaucrat, sysop, etc.), and may have their own 
local group, too. Clearly, there must be some platform, or structure, through 
which the designated LP members and the FSF can collaborate. I imagined this 
to be a LibrePlanet project, i.e. LibrePlanet:LibrePlanet. All FSF details 
are then found on the project page, while the LP staff are on the group page. 
In this way, FSF staff can register as LP users, but as 'project' members, 
while the designated LP staff can be members of both the LibrePlanet group 
and LibrePlanet project.

However, it occurs to me that the distinction is not important because we can 
reorganize pages as and how we see fit. On the one hand I'd like to 
facilitate habits consistent with my proposal and avoid the inevitable 
'resistance to change' (e.g. I've always done it this way), on the other hand 
there is nothing wrong with people using the wiki as they prefer.

>
> I don't know what you mean by a "form based wiki".
>

This is a novel concept with wikis, but not new. I have included forms into 
the navigation system, so users (registered members) simply click on a menu 
option, and if the page does not exist, the proper form will be displayed. So 
users need never edit pages directly. In this way, the menu bar defines the 
range of pages (news, FAQ, events, etc.), while the forms generate the pages, 
in some cases 'automatically' (without user intervention). The most frequent 
and common activities will be exclusively handled by forms, so users will 
experience the wiki as specific forms, rather than arbitrary wiki pages. 
However, users may create their own pages, so they're not locked into only 
using the forms.

> Wiki editing involves a lot of deleting and altering each other's work,
> with the idea that no change is irreversible, so discussion can always
> happen after changes and things can be put back fully or partly.

This was my understanding. I did revert changes, but then discovered the 
templates had been cleared and categorized as 'broken'. I expected some 
comment before taking that action. I assumed there was general consensus that 
the templates weren't useful.

> Especially at this stage of early development I don't think any of us
> can expect a conversation requesting permission to edit our changes.

Well I did. As you know I have spent some time analyzing local groups (and 
still am) and have written a couple of documents about it. Perhaps it was 
unrealistic to expect everyone else to share the same interest. I am not yet 
able to whip up a few pages (as you have done so effectively) with little or 
no prior planning. Furthermore, my pages are not isolated, and therefore 
freely editable, but rather part of a developing _system_.

I can live with the fact that people create random pages and will edit mine 
like they do their own, but hopefully people will also realize making changes 
can have far reaching consequences on _this_ wiki.

I do want to balance the ability to create random pages as the situation 
demands with a systematic approach to developing local group networks.

>
> Plenty of your work is still standing, and your work has enabled us to
> get to where we are. It's up to you, but I know people here have
> appreciated what you've done. Sorry if we haven't expressed that.

Thank you, but I prefer to see people taking my efforts further, rather than 
just acknowledging them. I think I am partly responsible for the situation, 
though, because I haven't been active on LP, so people don't know what I am 
planning.

The reality is, I know exactly _what_ I want to do, just not _how_ to do it. I 
have focused development on my wiki, to avoid spamming recent changes and 
confusing users with rapid changes in functions, templates, and forms on LP. 
I have seen your todo, and there is some overlap, so perhaps I should setup a 
todo as well, so we can pool resources and effort.

There are several issues with implementing forms (naturally), which I have 
been working on trying to resolve. The main issues still outstanding are:

1- Joining groups/projects/meetings etc. Basically, a form does not know the 
current user name, but, stupidly, has to ask the user and cannot verify the 
user entered a valid (never mind the real) user name. There is a way to make 
the user name available, but requires non-caching (itself non-trivial) on a 
per-page basis. Membership forms depend on knowing the user name, so this is 
a critical issue.

2- The calendar is a tag and its attributes are not parsed. What this means is 
you cannot put the calendar in a form and use the form to set the attributes 
(such as local or public name). This is a well known problem in wikimedia, 
which I have not yet resolved. Ideally, the calendar should do the parsing 
for template field names, but it gets complicated. My immediate solution is 
to simply include the calendar in the form and let the user setup the 
calendar manually. So in all cases, the calendar will default to 'public'. 
The issue mainly arises for new pages, once the calendar has been setup there 
is little need to edit it.

3- Projects. I am not sure how projects should be laid out, so they're not as 
developed as the group and user. My hope is that the FSF/LP will state its 
requirements, which can be translated into a typical project. I'd also like 
to revisit Manchester group, to see what project things they do.

4- Documents. I am less certain how to manage documents than projects, 
particularly their formats. I would like to create a 'virtual library', where 
the documents can be cataloged and managed (not necessarily categorized). I 
have been looking at several document formats (such as memos, proposals, 
etc.), so users can immediately select the appropriate type (as a form). I am 
thinking back to LibrePlanet2009 where users needed to note and collaborate 
during the conference. There will be several places where users can create 
documents from the navigation menu (such as their user page), so they need 
not 'go to' any specific page to do this. By documents, I mean any page that 
has more than personal interest (e.g. a todo page is a document, a profile is 
not).

5- Translation. I have already been asked to localize the menu options. This 
is somewhat problematic because the menus work with properties and depend on 
the menu name. I haven't yet looked at how smw forms do their translations, 
so the promised localization remains just that.

6- Robots. This is a fascinating subject, which I hope we will be able to 
utilize at some point. For me, it will mean we can manage all the 
regional/area pages more effectively, and, possibly, reorganize the group 
pages as well (some are not templated, nor in the group namespace).

My current status is, the group main page is fully functional, except for new 
members. This includes complete categorization of properties, templates, and 
forms. Users and groups are associated through member properties, so a user 
can check their membership page to see what groups/projects they belong to. 
Groups can check their membership page to see their members and current 
activities. I have created several 'helper' templates for category and 
property, which simplify associating forms to properties and categories.

Originally, I thought we could just install the templates and forms and start 
using them. I now think it better to hold off and let people 'discover' what 
works, and then template that.

After looking at some recent forums, I noticed several recurring 'arguments' 
against Free Software, which I think LP members should work on, but I'm not 
sure how to categorize them. I think this could be a standing project where 
we can identify the key points and formulate suitable strategies. I'd like to 
see groups compiling and evaluating these arguments, so we have concrete data 
to work with. The goal, of course, is to nullify them.

At first I thought of setting up distinct copyright, patent, nda, drm, and 
intellectual property rights sections, but I now see the dominate usage is in 
the commercial sector, so perhaps we should target it. In other words, we 
should define drm, for example, in terms of business ethics/practice, rather 
than a general ethical issue. This will open dialog with the commercial 
sector regarding 'generally accepted practice' (GAP). Clearly, we would 
advocate non-patented software/interfaces/formats/protocols as GAP and create 
some critical review of WIPO and similar organizations. For users, we could 
recommend they don't buy products with stated patent notices (e.g. 
bluetooth). While Eben may be correct that the public will not respond well 
to 'refuse to buy x', we just need to create an aversion to buying patented 
products (admittedly all products have patents), so businesses will be less 
inclined to make patent claims and therefore reconsider patents as a viable 
option.

We, too, need to show how businesses can survive without patents et. al. and 
still remain competitive. I think this is a major issue because businesses 
assume these legal instruments are critical to, if not define, business and 
commercial activities. Unless we can demonstrate vendors can remain 
competitive while disclosing all their source, the resistance to Free 
Software (but not open source), will remain high. A few people, and my own 
experience, assert that very few users are actually interested in the source, 
so they will continue to buy from the vendor whether or not they have it. 
Competitors will, of course, examine the code closely, so technically, the 
vendor may lose, but not necessarily their sales. However, some source is too 
costly to examine (e.g. Gnome, or X), so less likely to be extended in 
competitive products. Patents and nda's are even more problematic because 
they're intangible, and yet as important, if not more so, than copyright to 
influential businesses.

I think the these two issues are a good starting point in defining LP's 
ethical position because information is readily available and understandable 
to most LP users. I am not sure whether they should be presented as a ezine 
(trade journal), documents, or activism. The amount of software already on LP 
suggests an ezine trade section might be more appealing.

Regards,

Peter