Zum Inhalt springen.
Sympa Menü

ag-meinungsfindungstool - Re: [Ag Meinungsfindungstool] (proposal) Metagov as a technical plug-in framework

ag-meinungsfindungstool AT lists.piratenpartei.de

Betreff: Ag-meinungsfindungstool mailing list

Listenarchiv

Re: [Ag Meinungsfindungstool] (proposal) Metagov as a technical plug-in framework


Chronologisch Thread 
  • From: Michael Allan <mike AT zelea.com>
  • To: Start/Metagov <start AT metagovernment.org>, AG Meinungsfindungstool <ag-meinungsfindungstool AT lists.piratenpartei.de>
  • Subject: Re: [Ag Meinungsfindungstool] (proposal) Metagov as a technical plug-in framework
  • Date: Mon, 19 Nov 2012 12:31:30 -0500
  • List-archive: <https://service.piratenpartei.de/pipermail/ag-meinungsfindungstool>
  • List-id: <ag-meinungsfindungstool.lists.piratenpartei.de>

Alex and Ed,

Alexander Praetorius said:
> Hey, looks great - I still dont have any clue of how this toolbar
> works, but it feels like progress and thats a good thing. / I mean,
> i dont understand the workflow, but its fun clicking around :-)

Thanks Alex, we've been trying hard for that effect! We may need to
repeat it for step (b). It's possible we'll have a complex message
that can't easily be conveyed in a single banner. (more below)

Ed Pastore said:
> This [mirroring of wiki] of course doesn't have anything to do with
> the list server archives, but I think it's relevant because it means
> we would need to support a pretty vanilla web host environment,
> since the mirrors could all be different.

Mirroring could later be augmented by bots. MediaWiki has an API that
enables remote bots to accomplish anything a user can. It's enabled
by default. Even bidirectional mirroring is possible (though trickier
to code), where users can edit the content from any site.

More broadly (and I guess this has always been an aim for Metagov) we
also want to replicate our tooling and practices to other communities
and so spread outward. Vanilla hosting would be helpful here, too.

This might be a 3rd message to include in the framework banner for
step (b), if we agree:

1. Choose any toolset you want.
Go ahead, turn the dial...

2. Put your own toolset here.
Here's how...

3. Use this framework in your own community.
Here's how...

But I'll look into a quick design (a hack) for the "dial". Once we
have that working, we can put up any message we agree to. (I guess
there's lots more to agree to down the road, too. If we start using
the tools at some point, then it should all come together.)

> ... As I am trying to get at above... is tux a proper place to go,
> or should we look for something more flexible/powerful?

I have almost no experience with remote hosting. If we succeed (which
I don't doubt), then we'll need a super flexible host at *some* point.
I guess we have two approaches to upward migration:

* Many small steps (expensive time wise)
* A few big steps (expensive $ wise)

I'm feeling a little richer in time than money just now. ;^) So I'll
start by looking at what Tux offers in terms of a mailing list (looks
OK for a wiki). I'll multi-task between that, the plug-in framework
and Votorola work.

Mike


Ed Pastore said:
> Hi, Michael. A few responses in-line below.
>
> On Nov 18, 2012, at 3:41 PM, Michael Allan wrote:
>
> > Suppose the switch had two positions instead of one: (0) banner ad,
> > and (1) Votorola. Not sure exactly what would go on the banner ad,
> > but somehow it would do the job of (b). And (0) would be the default
> > position, ofc.
> >
> > If the switch UI (dial or whatever) were close to the switched views
> > (banner ad, toolsets), then the user could change toolsets on the fly.
> > Maybe the ad could even invite the user to operate the switch and see
> > what's on offer. Should we look into a quick design for this?
>
> This seems both elegant and useful.
>
> >> Also, what do you need from me to deploy?
> >
> > To do the same with the list archive, we might use something like
> > Apache Substitute. We'd need info about the host web server:
> >
> > * Is it Apache?
> >
> > * Does it support mod_substitute, mod_sed, or mod_line_edit?
> >
> > * Where in the file system is Mailman's public archive directory
> > (mailman/archives/public/) that Apache serves?
> > http://www.gnu.org/software/mailman/mailman-install/node10.html
> >
> > * How do we configure the service of that directory? Via central
> > config files, as here for example?
> >
> > http://havoc.zelea.com/system/host/havoc/etc/apache2/modules.d/50_mailman.conf
> >
> > Or via a .htaccess file in the directory itself?
>
> I'll answer most of these together. I am using a small cPanel account,
> which is fairly restricted. Yes, it is Apache (2.2), but I don't have a lot
> of power within it. It does not (and I checked, it will not) support and of
> those modules. Additionally, apparently this provider does not give me
> direct access to the pipermail archives. I now recall looking into that
> before: to migrate the list, I need to get the help of their tech support
> to get at the files.
>
> So all of that may be further impetus to move away from this host. I have
> not looked into what Tuxfamily supports nor what capabilities it would
> provide.
>
> This leads me to a tangent... I had at one point been thinking of setting
> up metagov as a mirrorable site. There is no perfect mirroring of
> mediawiki, but it is my understanding that I could make backups of it
> publicly available, and other people could make restores of it to their
> sites, thus making effective if slightly out-of-date mirrors. (They would
> just need to suspend edit capabilities and instead drive people to the
> master site for edits.) This would allow us to have some freedom from the
> authority of a single administrator (uh, me, for now), as other admins of
> other hosts could fork if they think I've gone rogue. :)
>
> This of course doesn't have anything to do with the list server archives,
> but I think it's relevant because it means we would need to support a
> pretty vanilla web host environment, since the mirrors could all be
> different.
>
> > Meantime, I can look into what's involved in migrating to TuxFamily.
> > Is this the latest information on that?
> > http://www.metagovernment.org/wiki/Upgrade_backlog#TuxFamily_Migration
>
> Yes, that's where I left it (quite some time ago; ahem). As I am trying to
> get at above... is tux a proper place to go, or should we look for
> something more flexible/powerful?




Archiv bereitgestellt durch MHonArc 2.6.19.

Seitenanfang