[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libreplanet-dev] LibrePlanet development
Re: [Libreplanet-dev] LibrePlanet development
Fri, 7 Aug 2009 22:35:22 +0000
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
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
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
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
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.