Greetings Habari Developers!

This week we finally released Habari 0.4!  Congratulations to everyone
involved in the process!  It's been a lot of hard work and a lot of
improvements have been added.  I'm really excited by what we've been
able to accomplish and am looking forward to what we will do next, which
is the main reason for my writing today.

As you may know, we're gearing up for a couple of interesting things in
the coming months:  PodCamp Ohio and Google's Summer of Code (SoC).

As a short mention regarding SoC, we have reason to believe that Google
will start to release information on the this year's project in the
coming week.  I would like very much for Habari to be one of the
participating open source projects this year.  We have an amazing,
sharing, welcoming community and an obvious desire and ability to bring
more people into our project.

I'd like to be prepared to present Google and potential students with a
list of viable ideas for our project.  If anyone has any particular
suggestions, please voice them to the list.

Now on to more pressing matters...

PodCamp Ohio seems like a strange milestone for Habari, but I think it
represents our first step into moving Habari into the net consciousness
as a mainstream blogging application.

To really make Habari ready for PodCamp Ohio, I see four requirements we
must achieve and release as 0.5 before June 28th:

#1/4:  We must adequately support podcasting.  Podcasting has been in
our to-do list since before most people knew Habari existed, and we
haven't really done much to achieve this goal so far, but this item is
absolutely essential if we intend to convince podcasters that Habari is
useful to them at June's event.

Primarily, Habari needs to allow the creation of new posts that are
"Podcast episodes" and contain any data that a podcast requires beyond
standard post data -- Like audio files.

We need to choose target client applications of podcasts and verify that
they work with Habari's feed output.  For example, we would be missing
our target completely if we did not successfully allow an author to
publish a feed that was readable by iTunes Music Store.

We need to make it easier to publish podcast audio than other blog
software.  To do this we should refine and connect the media silos to
the posting interface and make sure it is possible to do this with a new
content type - a podcast.  As an added bonus, we could attempt to enable
some interface for recording and saving podcasts to silos directly from
our UI.

We're already gold sponsors of PodCamp Ohio, and as thanks for all of
the monetary contributions people gave to make that happen, I think we
need to make the best impression on the people whose attention that
money buys.

#2/4:  We must produce a plugin and theme directory.  This is adjacent
to our need to make Habari itself presentable, simply because the first
question that anyone asks these days after hearing that Habari is new
blog software is, "What themes/plugins does it have?"  We need to say,
"They are available here from this central location."

My vision (which is completely malleable, but I present it so that we
have a starting point for quick discussion) is that we use the Habari
instance already installed at habariproject.org to house the
directories.  We would add two custom content types, one each for
plugins and themes, and allow developers and themers to add their own
content to the system.

To make this a reality, we need to finish the permissions system.  There
needs to be a way to give out free access to the Habari instance on
habariproject.org without giving every user account access to all of
that installation's features.

Also, we will need to consider what data we want to store about plugins
and themes, build the content types to house that data, create templates
that display the data in a useful way, and allow visitors to obtain the
things we list in the directory.  The directory should also be
responsible for automatically controlling the update beacon for new
plugin and theme releases.  I do not want to delay the directory
functionality for a better design for the hp.o website, but if a better
design suddenly appears that incorporates the directory, that would be
fine by me.

#3/4:  We must revise the admin theme and provide additional in-core
themes for use.  This goes directly to making Habari presentable to a
group of people we're trying to convince to use it.  The second question
people ask when they hear you have new blog software is, "Can I see it?"
  I'm anxious to have something beautiful to show them.

There was little talk here on the mailing list of Mike's Monolith
design, although there was plenty of admiration at his site.  I know
that while there are many people who are in awe of his design, there are
some folks with objections to it, specifically in that it is "not here".
  I suggest that, as Chris Davis recommends to me, we do everything in
our power to bring Mike "in" with his design so that he can benefit as
part of our community and we can benefit from his design expertise.
What the next step to affect that is, I don't know.

I think this item is probably the most challenging on this four-item
list, not because of the technical requirements to accomplish it, but
because a lot of people are going to have to compromise in places they
have been steadfast on and cooperate without the previously demonstrated
animosity if we ever hope to see this happen.

Regardless of the admin, we also need to consider k2.  k2 is a great
theme, but many people associate it to WordPress.  It would be ideal if
Habari also had it's own signature theme to face the world.  For that
reason, I want to start the selection and revision process for at least
two themes to include as part of the core distribution.

I have mentioned on IRC that my shortlist of three consists of Charcoal,
RedArry, and Mzingi.  I am open to other suggestions or new submissions.
  Any accepted theme will need to be vetted for licensing and be
code-complete.  We might also develop a minimal "training theme" that is
both simple and saturated with code comments and links to documentation.
  We should do our best to include at least one theme demonstrating
functionality that you can only do with Habari so that when our themes
are appropriated for Wordpress.com like Garland was, we can still offer
a home-field advantage.

#4/4:  We must update and organize our documentation to be as useful to
end-users as possible.  We need to pull together to document the things
that are missing from the code documentation we already have, and to
organize the documentation into a structure that makes it easy to find
what you're looking for and to place new items.

An idea has been floated on IRC lately about doing a "wiki week".  I
think this is a great idea, provided that we're able to pre-organize a
structure for new documentation to be in, or use part of the week to
arrange that.  I have no desire to see the Habari wiki turn into a
quagmire of duplicated information with vast expanses of things that are
missing.

It is our responsibility to our users to see that the wiki is complete
and the documentation that ships with Habari is culled from the top-tier
of wiki writings.

The above four items above are huge.  Nonetheless, I think that we can
accomplish all of them before June, and throw a few other goodies in to
boot.  If we work together toward these goals, I have no doubt that the
people at PodCamp Ohio will be stunned with what Habari can do, and
we'll ultimately succeed in positively expanding our community and
improving our project.

Thanks for reading.  I look forward to your replies.

Owen

And my congratulations to you all on 0.4 as well.
With regards to the podcasting integration, I've been mulling over how to
approach it interface-wise. The problem is that while I've podcasted a bit
myself, my experience is really rather insignificant with regards to what's
needed for serious podcasters. In designing Monolith, and thinking I might
tackle podcasting at the same time (which didn't happen, obviously) I looked
over some plugins for WP that are supposedly 'THE BEST!11', and while they
do provide a whole slew of dials and inputs, they also felt really confusing
to me.

There's been some talk previously, on this list I think, about what such a
plugin might contain, but it might be worth taking up again and chalk up
some basics on its functionality. Personally, I think it's worth keeping it
as simple as for instance the flickr silo.

As for all the other non-Monolith related things, I'm itching to help out,
but must also realize the meager confines of this flesh golem that is my
body. Drat. So instead I'll be focusing entirely on coding up Monolith and
getting her as ready as I can as soon as I can. I have a dream of getting it
done by May 5th, which I heard was the 0.5 deadline, but since I've also set
off April as my 'write a screenplay'-month, I'm not sure that'll happen
entirely as planned.

But, perhaps if I get the basics up and running as fast as possible, and
push the complex things to the back of the development, even though that's
what I want to do the most of course, it will be possible to integrate it
even if it isn't 100% done; as long as it's fully functional on a basic
level.

I've started coding it (already butting heads with IE; which reminds me, are
we actively supporting IE6?), and hope to find a JS-savvy person (kind of
hoping Steve Lam from K2 will come over; he'd be great to have on this) and
perhaps a core-savvy person, to bring to fruition some of the more nutty
ideas I had.

Give me a few days, and I'll have some Monolith repository going, so whoever
might be interested in working with me on Monolith can do so in an orderly
fashion :)

And again; great job guys, I'm amazed at how fast this thing is moving.

- Mike

On Feb 23, 5:59 pm, "Michael Heilemann" <heilem...@gmail.com> wrote:

I agree.  I'm anxious to start this talk so that we have a concept we
can complete with code before the PodCamp.

I'm happy to have what time you can offer.  Bear in mind that we're
all here to help.  If there are even some things you're not too
precious about that you can toss to the rest of us, we're willing.

As I said, there are plenty of us waiting to help, and we do have the
skillset you're looking for.

It was suggested, and I agree, that we should set up a branch in the
core repository for this and offer you access to it.  This will make
it easier for the community to be involved, and save the trouble of
setting up a repo of your own.

Let me know if you want to do this, and I will arrange it as soon as I
see the email.

Owen

* The oft-talked about "Habari Control Center" from which one can
manage multiple Habari blogs.
* a backup mechanism
* revision control on posts
* importers from other tools
* an export mechanism, preferably to some standard format
* possibly the creation of said standard export format
* support for mobile browsers

Yes.

To this end, Habari ought to support RSS 2.0, either in core or in a
plugin.  If we want to be a podcasting powerhouse, it seems strange to
me that RSS 2.0 would be a plugin; but then it has not yet been
established that we do want to be a podcasting powerhouse.  We might
be satisfied with a "podcasting powerhouse plugin pack" that provides
all the necessary functionality.

While that last bit is a neat idea, I think it might be putting the
cart before the horse.  I surmise that many podcasters have very
specific workflows, and that the acts of recording and editing are
completely divorced from the act of publishing.

I'm not a podcaster.  If you know a podcaster, ask them what they like
and dislike about their current tool(s).  Let's find out where the
current weak spots are.

This is independent from the current -extras repository, right?  When
you say "directory", do you simply mean a collection of links to
externally hosted resources; or do you mean a hosting solution for
said plugins and themes?

This would provide the "home page" for plugins and themes, right?  The
code would still live in some repository somewhere else, yes?  Or are
you proposing that one could upload a zipfile of the plugin/theme to
be attached to the post on hp.o ?

I think this is an acceptable idea, regardless of how or where the
stuff gets stored.  Is it your vision that anyone can register an
account and start creating theme or plugin pages?

I think permissions needs to be done for 0.5, anyway, so this fits
nicely.  I have been formulating some additional thoughts about
permissions, but I will put those into a new post.

I think this all makes sense.  When a new version of the plugin or
theme is available, the author can update the post on hp.o to indicate
that, which would trigger the update beacon.

I am very much in favor of a branch in our repository to which Michael
has commit privileges.  Then, the current pool of committers can
collaborate on the development and implementation, and we can leverage
our expertise of the Habari core.  Additionally, this allows us to use
our existing Trac installation to permit the filing of bugs against
Monolith.

I think it's important that this be implemented in the open, with a
public revision control history, so that folks can "follow along at
home".  I also think that if the intention is to use Monolith for
Habari, we should integrate its development into Habari's current
system as early as possible: everyone with a Subversion checkout of
our root directory can immediately get the Monolith work-in-progress
without having to fetch it from somewhere else.

I'm a strong +1 on all three of those themes.

I'd also like to put forward the notion that we consider making
versions of the default themes for all our theme engines.  I think it
would be nice to demonstrate the flexibility of our theme system.  If
not all the themes, then certainly the "reference" theme should be
made for RawPHP, Smarty, and the StyleCompetition engine (if it still
exists).

Absolutely.

We have a fair number of new users coming into Habari with the release
of 0.4.  I think we can and should connect with them to have them help
identify weak spots in the documentation.  Some are new to Habari
altogether, others are re-approaching the project now that we're more
stable and functional.  Either way, these are the folks for whom we
want to supply documentation, so let's get them involved.

I am extremely excited about the near future for Habari!

Cheers,
Scott

I second the suggestions for the export system/format. Another idea is
the terribly named "comment-back" idea we've thrown around a bit.

*snip*

I'd like to float the idea of a slightly more formal level of ownership
within the community. What I'm envisioning is that once we have the
major goals of the next release, that community members can choose goals
they would like to work towards. Perhaps we could add a "component" on
trac of "goals" and use that as a sort of gathering point for people to
work on coordinating their efforts. For example, we could set a Goal of
"Podcast Integration". We'd then create a trac ticket with that title.
Then anyone interested in contributing to that goal would be able to use
that ticket as a central location for recording ideas and posting
patches and such. Idealy, I think someone would volunteer to be the
"owner" of the goal and help make sure that things kept moving forward.
This way if someone is curious as to the status of (for example) ACL,
they know who to ask.

Any thoughts on how to make such a process work?

I am all in for the 'plugin pack'. Although including the feature in the
core does seem appealing, I needs to be as core plugin(s), IMHO. One
advantage I can think of is to keep the code as 'light' for non-podcasters,
and at the sametime, Habari's support to podcasting would be no less
official, considering that the core plugins are part of Habari's
distribution.

I think I'm in favor using the existing trac for Monolith as well, We can
simply set a temporary 'Component' for it, and remove it when it is finally
merged with core. I concur that this will keep it part of Habari's main
development flow

I strongly agree with Scott. Besides the self-centered urge I'm having to
touch what's all about, I think this will enable all people involved with
Habari to test Monolith and continuously provide feedback. This would
minimize the time Monolith will take to get integrated.

Tell me about it :)

--
Ali B.

"No one can make you feel inferior without your consent."
--  Eleanor Roosevelt

[snip good stuff I'll think about later]

Is there site map functionality for the wiki? I think it would be
easier to organise and to work out what's missing if we could have an
overall picture of what's there.

Related to earlier discussions on this topic, I think introductory
user focussed pages that link to related developer content is broadly
a good way to structure things.

If people find there are things missing from the wiki, new tickets
should be added under the documentation component on trac. For
consistent documentation, I also think a style guide for the wiki
would be a good idea (what voice should docs be written in, Habari
should be capitalised and without other formatting, etc).

A wiki week is an excellent idea. I suggest we do this midway to 0.5,
so we can incorporate and document features and fixes, and in the
meantime consider what the structure might be. Say, the first week in
April?

Were there specific ideas floated about what we should do in a wiki
week? Obviously we want to try to improve the documentation, but I
think we need to have some clear goals about how that might be
achieved. Another goal might be to get new users to visit the
wiki--and hopefully provide feedback--even if they don't contribute
directly to it.

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog

On 24 Feb 2008, at 02:45, Scott Merrill wrote:

How much do we want to get within the backup?

Within posts, the biggest issue I see is actually saving the post type  
(i.e., page/post). No existing standard format is made to explicitly  
cope with post types (so using categories for them would likely be the  
only way, probably with some prefix).

--
Geoffrey Sneddon
<http://gsnedders.com/>

The tone of this response indicates to me that you're already looking to
fit Habari's data within some pre-existing format, probably Atom.

Let's not jump the gun.  Atom doesn't include most of the datapoints
that Habari stores, and extending it is a non-trivial amount of work.
It might actually be better to use some other format for storage.

While I'm sure this is what WordPress was thinking when they invented
the atrocity that is WXR, I think we can do better, even if we end up
extending Atom with a standard layer for blog export.  What I would like
most for this feature is to collaborate with other projects to produce a
common export format.  If we could contact some of the folks in other
projects (MT, TxP, s9y, EE, etc.) and get them on board, this could
actually be a useful feature.

Owen

Yeah, that's the "added bonus" part.  Perhaps this could just be a
plugin on top of what podcasting capabilities we provide.

If there's someone who knows Flash out there that doesn't know how to
otherwise contribute to Habari, I'm giving them the heads-up early.

Our directory would be just that:  A directory, not a repository.  It
could integrate tightly with our own repository, but it would be open to
linking to plugins stored at other locations.  We should also try to
integrate with external svn hosts that house Habari plugins, so that we
can offer the same features for remotely hosted plugins that we offer
for those out of our own repository.

As far as offering storage for the plugin downloads themselves, I think
we would be wise to offer a mirror of the most recent live plugin
version.  Too many plugins go missing of become unavailable over the
course of time.  I think it would be important to capture those and
provide an alternative for download.

I wasn't really proposing that we alone host the plugin file, but I
suppose that we could offer that as a possibility if the plugin author
desires.

One of the bigger issues that plugin developers might have with hosting
their plugin downloads with a service is being able to track interest in
their plugins with download counts.  While I want to provide this
functionality, I also want to make sure that plugin authors still have
control over their own works, particularly in that it is a pain to
update the plugin archives at a bunch of directories when if they
pointed to your own download file, you could track and maintain in a
single location.

Also of concern in the past was the idea of posting advertising on the
plugin's download page.  For many people, writing a plugin for free
download is a way for them to attract visitors to their site and get
some ad clicks.  For people who give away their work, I have no problem
with trying to make a couple cents from a pageview.

Ideally, I would like a plugin author to provide us with a download
link, which we would redirect to after counting the download click for
their plugin.  I think it's reasonable if this link isn't "direct" but
links to a page on the developer's site that contains the direct link.
In that case, they must also provide to us a true direct link, which
we'll only use to keep a mirror and monitor changes.  If they want to
host the plugin archive with us, we can automate that - but it should be
clear that this is not a requirement for our directory.

There are many positive reasons to do this that I left out of my
original message to keep it "brief".  Having early review (the code
part, not the design part) is essential to avoiding massive changes at
the end of implementation.  More eyes looking and more hands working is
always better.

  > I'd also like to put forward the notion that we consider making

This is an interesting idea, although there are a couple of hurdles:

We don't package Smarty with Habari, IIRC, due to licensing issues.  So
any Smarty theme that we package in the core won't work without doing
something more.  Maybe we could provide such a theme separately with a
Habari-specific Smarty download?

There is no StyleCompetition "engine", it's just a HTML framework that
you can hang additional CSS on.  I have a single-column version of the
Style Competition HTML with integrated Habari code in my working copy,
but the system needs a 2- and 3-column version to be complete.  I'll
post it to the -extras repo so that people can look or add.

In order to make this work properly, we'll need to implement theme
options, so that you can select what style you want to use with the
HTML.  Hopefully we'll see that in 0.5, too.

Owen

I've worked a bit on some of the StyleCompetition stuff myself, and I've
reached a sticking point too, So I'd be happy to upload that somewhere
as well.

In addition to this, may I suggest two things to go along with the
plugin structure?  I am a new user of habari, and you all deserve some
major props for it, it's a great package.

1.) Some sort of standardized method of plugin packaging - most that I
have played with are in zip format, with the directory intact - making
it absolutely simple to install.  But a few I tried were only
available via a php view source display -  As pasting text into PuTTY
is sketchy at best, it made for quite a few more steps to get things
in the correct place to work.

2.) A unified format for documentation, particularly when the plugin
needs something added to a template to display correctly (or at all).
On two of RN's plugins, it took me a few minutes to find the proper
way to output what the plugin was doing (yes, I know I didn't read the
documentation, but the way the wiki is laid out now, I made the
mistake of assuming that a download & activate would be enough to add
it to my blog).

Just my $0.02 - keep up the great work!

Please define what you mean by "atrocity" in re: WXP.  In what ways
could it be improved?  And why leave WP off the list of other projects
to contact?  We're not all Automattic employees on the mailing lists
and I, for one, can tell you that having a unified export format from
MT, TxP, Geeklog, Habari, etc. would be wonderful.

In fact, where's the blogdataportability.org effort?

--
-Doug

http://literalbarrage.org/blog/

Welcome to Habari :)

The plugins in the habari-extras repo are packaged and can be downloaded
from: http://www.habariproject.org/dist/plugins/

--
Ali B.

"No one can make you feel inferior without your consent."
--  Eleanor Roosevelt

The issues with WXR are readily apparent when you try to do anything
useful outside of WordPress with real WXR output.  In particular, one
major issue bars any usefulness of WXR as a viable input format.

WXR, although it looks like XML, is not guaranteed to be well-formed
when it is exported from WordPress.  As such, you need to build a
completely separate parser to handle the file that WordPress produces,
rather than use existing parsers that can handle well-formed XML.
Writing a separate parser to import WXR may be useful for exclusively
importing from WordPress, but makes little sense for using it as a
dedicated interchange format.

Insisting that WXR be well-formed and changing WordPress' support of WXR
to enable this would likely break WordPress' backwards-compatibility for
its own export format.  Poorly-formed exports from current versions of
WordPress would not work with parsers in the future that required
well-formedness to execute.  Historically, WordPress bugfixes that
address these issue are applied on the input side rather than the output
side, indicating that they seek to maintain this backward-compatibility.
  As a result I think it's very unlikely that such a change, which would
require that the output be valid XML, would be accepted.

There is a myriad of other problems with selecting WXR as a standard
interchange format.  A major one is that there is no published standard,
just the output that WordPress itself produces.  While I'm not expecting
anything quite as complete as an RFC, no embryonic document exists as a
  reference.  Even if you assume that WordPress eXtended RSS derives
somehow from RSS to use that as a basis for documentation, RSS itself is
poorly defined, but paradoxically known to require well-formed XML
universally among all of its variants.

As for why I left WP off the list of other projects to contact, I
didn't.  You omitted WordPress from your list of blogging software to
contact in the same way I did.

But now that you mention it, I do get the impression that WXR is the
format that WordPress would like others to adopt for export, rather than
working together with other blogging tools to create an open published
standard and then implement it as part of the core offering.  It seems
to me that platforms that are not already maintaining interchange
formats they've developed independently would be more receptive to
working toward a universal solution.

Owen

I think it's an interesting idea to consider.

One thing that I think we've missed along the way is that we've wanted
to create more documents detailing the work that is to be done so that
people have direction to work from without having to contact someone to
ask their opinion.

I think with my "Looking Toward 0.5" message, I've effectively outlined
some of my personal ideas for the future of Habari, at least as a
starting point.  It is definitely possible to take each of those ideas
and expand upon it to work out how each piece will work, specifically.

Whether these items should have overarching tickets in Trac as "goals",
I don't know.  Would there be sub-tickets that relate to that parent?  I
think it might get a little confusing, but I can't think of a clean
alternative.  Maybe something in the wiki?  And then that documentation
could evolve into user or developer documentation for the feature?  Just
thinking aloud.

Trac is useful, but could use some usability improvements and be easier
to install and maintain.  The world needs better self-installed
open-source project management software.  When Habari reaches 1.0,
that's where I'm headed for a "vacation".  ;)

Owen

We should think very carefully before we invent anything.

http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages

I believe Atom with extensions is likely to cause way less pain, get
better buy in from other vendors, and get more support from people
with a lot of expertise than anything else we might try, XML or not.

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog

Perhaps so.  What I failed to emphasize in my post was that I think it's
in our best interest to first write down an absolute list of what we
need an interchange format to do, and then see what might be out there
to hold it.

This is as opposed to starting out with Atom as that format and then not
really knowing why we chose it other than thinking it might be close to
what we want.

Owen

That I agree with.

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog

On Feb 23, 6:25 pm, ringmaster <epit...@gmail.com> wrote:

I too think if we are setting a hard milestone for the admin, and that
there's a consensus that "monolith" is going to be given every
opportunity to *be* that admin, it should be in an official branch
ASAP.

~miklb

RDF

--
Matt Read
http://mattread.com

[snip]

There are quite a few things I think are interesting around search,
tagging, and suggest functionality. Some of these I've mentioned
before on #habari in relation to a research project that I'm currently
looking for an honours or masters student for, but if I don't find
someone suitable some portion might be suitable for GSoC. And since
I'm a student, maybe I could take time off from study to apply :)

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog

Here are some ideas for goals for a wiki week. Picking an arbitrary
week to get things started, how about 5 to 12 April?

=Wiki Week Goals=
* Update and organize the documentation to be as useful to
developers and end-users as possible.
* Make it easy to add good documentation in the right place by
providing categories and templates.
* Identify things that are missing from the documentation.
* Add documentation where required. For example, try to write all the
pages under wanted pages
(http://wiki.habariproject.org/en/Special:Wantedpages).
* Update and improve the quality of the existing documentation.
* Encourage people to visit the wiki.
* Make sure that pages are properly linked to each other and that
there aren't any orphaned pages
(http://wiki.habariproject.org/en/Special:Lonelypages).

=Wiki Week Prerequisites=
* An agreed organising structure.
* A documentation style guide.

--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog