I agree with that, I think that Bassel should check all blueprints and
he should approve all of them, but I don't know if he will have time
for that since there are some delays in response for him, and not
every issue/blueprint/bug is commented by him. It would be nice if
he's BDFL for Aiki and stuff would be implemented only if they will be
approved by him.
I don't know a tool for that but the way I think would be the best for
managing ideas is to have some kind of graph with nodes that are
features that are connected to other features and all stuff that are in
aiki is in this graph
something like ?
/
---------forms ?
/ \ /
/ \ /
AikiMarkup ----------- Widget System ----------- ?
| -------/ \
| -----/ \
Engine ----/ \
?
it would be nice to have a tool that allow to create that kind of
graf where in each node will be status (implemented, need rewrite,
discussion etc.) and you click on every node and you will see blueprint
and bugs related to that node.
We can put that file into git and everybody will be able to edit it.
I can create such graph in Inkscape (I think that there can be html
inside svg so maybe we can put links to wiki in the graph) maybe it can
be embeded into wiki page (since you can put svg inside html in modern
browsers).
The idea around Aiki was to help insert data into database via forms.
But for me Aiki should a tool that allow to rapidly create nice web
apps. So it need to be more powerful then just forms and widgets. I
also thing that we should implement markup I propose and use it as
default, because it allow to create such rapid applications. The idea I
have with aiki is to have a tool that allow users to change thinker
with everything, that's why my markup proposal may look complicated at
first and using php will look simpler, but if we use php there will be
no advantages using Aiki in first place. If there will be current forms
in aiki which is pain to use users will be using php instead, and if
they can use php instead why the hell they will want to use aiki. It
will be more complicated the just use pure php.
So what be left will be only Aiki API, so we end with a library which
nobody will use. I personally don't see the reason, except maybe
sentimental, to use Aiki if it only support php, the real power of Aiki
will be the markup that will allow to create complicated things in few
Aiki tags.
It's nice that you can use widgets to create layout that it's split-up
into chunks, but Aiki is suppose to allow to create applications, not
help creating layout. Which don't see the reason why someone would want
to use it to create such layout. Because you can create application much
faster using just php (without any aiki).
And another point is that Aiki should be also used by people that don't
know php, and have small knowledge about programming, we should give
those people bricks that will allow them to make powerful applications.
If we give them php they will not use it. We can give powerful users a
way to enable php if they can't do what they want using Aiki markup.
But WE SHOULD USE AIKI MARKUP. For instance for me I don't see the
reason to use php if I can use markup I propose, bacause I will be
able to create things I want in 2 lines except 10. I can build almost
every complicated code using few tags, and if there will be php I don't
see the reason to use Aiki, maybe except to improve the sites that
already use it, like OCAL or OFLB.
On Mon, 27 Feb 2012 21:32:46 +0800
Christopher Adams <christop...@fabricatorz.com> wrote:
> Hey guys,
>
> Let's keep this cool.
>
> It makes me happy to even see Bassel's name in my inbox, given
> everything that's going on. If he's back on this list more I take
> that as a very positive sign for his well-being. :)
>
> My reading of the situation is that Bassel realizes we took the
> infrastructure he built and kind of ran with it. He'd love to be able
> to go back and make the foundation to build on a little more solid
> and consistent with his original vision, which is to make Aiki great
> and work the way it was meant to. However, that might be difficult to
> reconcile with the current state of the project (including real
> commercial needs for some of us) and the expectations and plans that
> other more recent and active contributors have.
>
> I agree with jcubic that we should really stick to the bug tracker;
> for now, that's Launchpad. We've pretty much short-circuited the
> proposal–discussion–approval–implementation process. For my part I've
> stuck to reporting bugs and suggesting blueprints, which of course is
> not as helpful as actually implementing anything. Then again, some of
> the recent amazing features have (seemingly) come out of nowhere, and
> we don't want to be in the position of ignoring or discouraging
> contributions. But I profess I'm ignorant of any broader Aiki roadmap
> other than 'make it better'.
>
> So we all want to make Aiki better. We all have some good ideas. How
> to manage that? I would like to see a clearer delegation of
> responsibilities for how blueprints and bugs get discussed and
> approved. Maybe for each part of the project we should designate one
> person to approve blueprints for that part, and make it clear who is
> assigned to work on it. I think Launchpad can handle this, if only we
> can. :)
>
> Christopher
--
Jakub Jankiewicz
twitter: @jcubic
www: http://jcubic.pl
_______________________________________________
Mailing list: https://launchpad.net/~aikiframework-devel
Post to : aikiframework-devel@lists.launchpad.net
Unsubscribe : https://launchpad.net/~aikiframework-devel
More help : https://help.launchpad.net/ListHelp
