On Oct 13, 6:17 pm, Owen Winkler <[EMAIL PROTECTED]> wrote:
> It's been a strange past month for me, flying around the country,
> listening to people talk about blogging, internet, and other computer
> issues. During all of the conferences I've attended and conversations
> with people, I've been thinking about Habari and our road forward.
A month. Man, I only get two weeks like that every year, and they're
not even close together.
> A few folks have read recent posts on my about the survival of open
> source projects. I think one of the essential ideas behind communities
> that makes them long-lasting is a strong bond between the people that
> make up the community. As such, one of the most important things I
> think we can do within the next year has nothing to do with coding.
>
> I'd really like to start the discussion now about some kind of gathering
> of Habari developers and enthusiasts. Call it "Habaricon".
We might need to work on marketing. As for the con though, it would be
a good idea to do something like it. I would suggest in a larger city
that a larger portion of Habari user's could get to. Such as Boston,
New York, San Fran., Los Ang.
I personally live in Maine so I could only get to Boston and New York.
However, you would want to have a major event to do something like
that. If you have a con. and it turns out bad and nothing happens from
it then no one will ever go to another. I might suggest having a con.
prior to release 1.0 to break the news and start discussion on what's
next for Habari
> I know that people will have different opinions about how it should
> work, what we should do, and (most emphatically) where it should be.
> The only thing I ask is that when you're done suggesting your own home
> town for the location, you do two things: Consider where the best
> location will be to get the most people together at once, and think
> about what you can do on your own to grow a local sub-community of
> Habari enthusiasts.
@see above
> Another idea that I really liked from my recent trip to OhioLinux is one
> I learned from Jono Bacon, the Ubuntu Community Manager. He spoke about
> how there were many small communities inside of Ubuntu, and that
> "belonging" to any of the small communities or the larger Ubuntu
> community is a significant part of what makes working with Ubuntu
> appealing. I think we could do something similar, and even suggested to
> skippy that perhaps our next bug hunt could pit different regional
> Habari groups against each other for total bug crushing domination.
I am actually a member of two parts of the Ubuntu community. I am part
of the Bug Squad and the Quality Assurance. I find their system to be
challenging but affective. I might suggest we make groups such as:
// For PHP Core
* Bug Squad - Handles bugs currently in system
* Q.A. - People who are not apt for coding but can try out release
candidates, give feed back, report errors, etc. to ensure all releases
are at their best.
* Lead Developers - Handle new features and debug things the bug squad
can't.
// Designing and Themes
We need people who can work on graphics and the front end. Habari
looks amazing but as we grow new features will need to be added. For
me, using Habari in Firefox3 under Linux, the admin panel always seems
to mess up on the Plugin Configure. Dedicated people to designing and
fixing frontend will take care of this.
They can also work on creating new themes for Habari, or converting
themes from Wordpress to Habari.
// Documentation
People who are dedicated to keeping up the wiki and docs included in
Habari will become a requirement. Having the unfinished WIki right now
makes it difficult for people such as me to know what all the filters/
actions/other relevant information is when creating a Plugin or Theme/
extending Hbari.
// Support
If we want to expand and take control of more Wordpress users, giving
those people custom support will help. Having a team dedicated to a
support forum, or a ticket system, or just a chatroom will create a
much better environment for the new comers.
> I spend a good deal of time writing these long posts, so I'll just keep
> this last idea reasonably short and implementation-free.
Turns out I am spending quite some time on my response.
> With 0.6 approaching delivery - which might come as a surprise, but it's
> getting rather close to being done - I've been saying for a while that
> 0.7's focus should really be about theming.
>
> There are other points on which we could focus, and I fully expect that
> people will step into the leadership roles required to accomplish them
> (this is the topic of a long post yet to come), but now seems like a
> good time to implement themes, since people - especially themers - are
> starting to take more notice of our system.
>
> There are a lot of good ideas floating around on how to make a superior
> theme system to other tools that are available, but I don't think we're
> done coming up with them. We need to organize these thoughts so that we
> can implement something cohesive and streamlined when we begin to ramp
> up 0.7 development.
>
> A few issues to consider:
>
> * How do we best educate a WordPress themer (essentially the people
> we're trying to woo) to produce a Habari theme?
Most people are not willing to learn. However, those people will have
to. We can't use Wordpress's theme system because they're theme system
is based off a series of idiotic functions. Instead of a foreach as we
do it, and the $post->permalink, they do things such as a
while(have_posts()) and the_permalink and get_permalink. If we bloat
Habari with these Habari will soon become a mess.
I would suggest a support team and a full set of pages on the wiki
would be a good start.
> * How can we make the theme system more easily handle common theming tasks?
Now this is a good question. In modern Internet usage there are a few
key aspects to consider:
* XHTML is growing. Whether Habari wants to use HTML or not, many
designers use XHTML now. A compliance must be made.
* Ajax technology is becoming more common. More growth in Ajax related
handlers will be a nice touch.
* Mobile. Mobile browsing is the biggest thing we need to consider.
Wordpress released their "iPhone Support" a while back. Though I am
not a fan of the iPhone because I can't get it with my provider, many
phones such as it (Google G1, Blackberry, iPhone...) are huge. Having
some methods to detect if the user is on a mobile device without
always making custom code will be nice to have. Such things as <?php
if ( Browser::mobile() ) ?> or what you have it.
> * Is there a way to provide both WordPress and Drupal-style theme systems?
Drupal? You'd have to be insane to try and have built in support for
their themes. I would again suggest a support staff and documentation.
Providing features such as this will make Habari become a bloated mess
for those who use it because it's core nature.
You do have to consider that most people who use Wordpress, even the
lead developers, are far from being good at PHP and MySQL. Their
system is getting old, bloated, slower and slower, and it's not
looking good for the future of Wordpress. However, their frontend gets
users. Their backend is simple and easy. Habari's is too, except it's
hard to extend upon. The one menu idea is nice, but limiting, if we're
to grow, I think we should at minimum add support for submenus to the
menu. You can't hold much on the current menu and the fact that if you
add to the posttypes it auto creates two rows into the menu makes it
hard to truly use that feature wisely. We need to keep the menu simple
but be able to get user from A to B without having to goto C.
> * How can we simplify the configuration of themes and provide a user
> interface that common users can use to drive more complicated theme
> configurations?
Having more Theme Configurations over the Habari system is nice, but
then you get to the fact 90% of designers still don't know enough PHP
to understand the advantages. Most designers in the world don't know
PHP at all, most seem to prefer Flash and think it can do what PHP
does, but don't understand the difference. Then you have those who use
ASP and think they can learn PHP on the spot. However, you must treat
all these people with the same fairness. If we're to become a larger
community then we will need to have "support" for all these people.
(Yes, I too am realizing that a Support Staff and more Documentation
seems like a good idea.)
> * How can we do all of this and keep the system flexible?
Enough said.
> Obviously, I have a few answers for my own questions, but I'd love to
> hear other people's ideas. This area is where I intend to spend a good
> bit of my time when 0.6 is out the door, and I hope others will join me.
>
> A final thought:
>
> One of the more significant take-aways from Jono's presentation was that
> in a community like ours, we need to spend our time turning sentiments
> of "This sucks. And you suck, too." into "I'm gonna kick some ass." and
> actually accomplishing something.
>
> I think there's still great cause to be excited about Habari, especially
> as we close in on our 1.0 release. There's still significant ground to
> cover, but as long as people are willing to kick ass and contribute in
> any way they can, we can produce the kick ass product we know Habari can be.
>
> Thanks to everybody for being part of this. I'm anxious to hear what
> you think of any of the ideas above, or even any new ideas of your own.
I want to lastly say a few things.
To keep organization but have interaction of the community there will
have to be sections within the community and leaders within. I
specified above a few teams we could have (Bug Squad, Designers,
Support, Core Lead Developers, ..) but all these teams will have to be
small enough that the people in them will know mostly everyone, if not
everyone, and have a connection with them. I would suggest breaking up
the habari-dev mailing list and habari IRC into multiple chat rooms
and mailing lists that each group can handle. Above each primary group
should be overseers. For each release there will have to be work done
from each group and all groups will have to communicate, overseers
will help with this bridge, they will be people who are in two groups,
such as be a designer and a developer, or a bug tester and a
documentation writer. Those people will have a more knowledge in where
groups stand and because of this will have to be held in another group
where they can give reports. No one should have more power then
another person but for the sack of organization we must have a system
and keep communication within groups and from group to group.
Also consider that in having to keep the groups reasonably sized we
will have to have a few groups that can have any number of people
within it and have leaders that are the primary group members. I would
think that the Bug Squad and the Q.A. would be best for this. The bug
team doesn't need to be great at coding, but are there to give people
insight into habari and build their knowledge higher. The more Q.A. we
have the better releases we will have. Makes sense to me there.
> Owen
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
