Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Michael Shiloh]

rakshat hooja wrote:
> 
> 
> 
> It is already linked from the front page, but clearly from not those
> places it should be from :)
> 
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
> 
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org
>  etc. 
> 
> 
> You are right but I think that the problem lies in the fact that 
> Openmoko has not been able to provide any entry point where new people 
> joining the list (after the release of the freerunner) can figure out 
> who and where to ask what question. The Openmoko people are pretty open 
> and if you will ask for something long enough you will get an answer/ 
> access from them. Michael Shiloh of Openmoko used to interface with the 
> community and answer their questions after getting the information from 
> the developers in a regular community update. I think Steve and Michael 
> still do that? 

You are right, Steve and I still do that.

My formal job is to ease communication between the community and the 
company. As I am not in Taiwan I am somewhat out of the loop of many of 
the decisions and processes. In fact, as the OP suggests, I am that 
fuzzy person between the community and the company.

I've let Steve do the updates for the past while because as the decision 
maker on when and what to ship, he has much more visibility into the 
schedule than I do. There was clearly nothing I could contribute in that 
realm, and there is rarely anything I can add on top of Steve's updates.


Maybe we should have a page on the wiki describing who
> does what at Openmoko and who to address what question to

We have the beginning of such a wiki page, and I'll expand my job 
description.




  and also an
> introductory email for new subscribers listing out similar things.

Good idea. The best answer to the question "who do I ask this question?" 
usually is "it's better to ask it on the list, since (a) if the best 
person to ask isn't available, chances are someone else on the list will 
answer pretty quickly and (b) your answer will benefit others both now 
and in the future through the archives and perhaps (c) we try to be as 
open as possible. Ask on the list unless it is private. But your point 
is taken, and this should be in such an introductory email.


> 
> It has been almost an year since I wrote my first email to Openmoko 
> (actually to Sean  to which Michael Shiloh replied) I can assure you 
> that Openmoko people try their "hardest" to be open and responsive to 
> community suggestions/ questions. But often it takes time for the 
> question/ request to reach the correct person who can answer it / 
> respond to it.

Indeed. The degree to which we are all overwhelmed is astonishing. I 
have never worked at a job where each of us wore so many hats, and where 
each hat involved so much email and related conversations.

For example, I was thrilled yesterday when I got my _unread_ mail 
message count down below 1000. Whee!

We do sincerely try to do our best. Sometimes we fail because we don't 
know what is best, but usually we delay simply because we don't have the 
time.

We really do rely on the community to take some of the load off of us. 
This is why I was so thrilled to so the wiki maintenance volunteers. A 
well maintained, informative wiki will free up the time of Openmoko 
engineers to do what they need to do, instead of answering questions 
that are already answered in the wiki but simply can't be found.

I should add that we are very much aware that many of you on this list 
already perform this task and already reduce our workload by helping and 
answering. The well maintained wiki will help free your time up, so you 
too can be doing more important things (like helping us?) rather than 
answering questions that are already answered.

Along these lines I should mention that the testing, reporting, and bug 
filing that you are doing for OM 2008.8 is tremendously helpful. Please 
keep this up. An identified problem and a well defined, reproducible bug 
report saves so much time for the engineer assigned to fix it. Thank you.

Finally, my primary job is to keep you all happy. If you have any 
complaints, questions, problems, suggestions, or other comments, please 
do write me, either on the list of privately. It is both my job and my 
personal wish to keep and to further strengthen an involved, active, 
enthusiastic, and productive community. I still believe that the most 
amazing devices have yet to be imagined, and are more 

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Lisa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for posting that link Rashat!  I'm waiting for Stroller to get an 
answer too, but it's nice to know who to complain to about what after 
this :)
~  I want my KEYBOARD SWITCH back, I do!
~   Lisa
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFIjIa81sOMhsR36UsRAthKAJ4oMwaLF8ktJTOTN+N+4pg9D49mZQCgridn
MR21pkary5efNvY+F5myvjU=
=MAVw
-END PGP SIGNATURE-


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This problem is common to all the process / firms: who must to take the
important design decision?

There can be two possibility:

A) Who code

B) Who doesn't code but can have a global vision of the project


To choose between these two alternatives is not easy. Who code know well
how it run, what the hardware can do.

Who don't code, may have a global vision of the project, he know which
are the objectives, deadlines, etc. etc.

I am a programmer: when I receive a work I receive the specification and
I must follow it. It happen that from time to time I think: but this is
a stupid request / non sense. But I have to follow.

According me the best solution is a between A and B. B know where to go,
and A know which is the better way of to take it.
So, on openmoko will be a very nice thing that on the morning they get a
very good coffe in a table and A and B, because A can do nothing without
B and B can do nothing without A.

Then there is the thirth element

C) The end users

The end user are who in the end will pay and will use the phone. Their
request are important but there are two big problems:

1) Often C don't know how it is running
2) All C's have different needs and different wishes. Is impossible to
have all the persons happy.

An example GTA3 must to have a camera? For me is NO, for another person
may be the same, but for another is very important to get it.
Who must to win?

So I think decisions must be taken by A union B reading from time to
time also what say C. A opensource project / phone DOESN'T mean a
democratic process.


In a future I hope that some persons will start to build a S.O. for
Openmoko but driven by a different organization.
This will let Openmoko to put all his resourses on the hardware part,
while the SOFTWARE part is managed my another organization (Like it
happen now with PC and OS)

But in every case, it is only a my idea :)

Regards
Michele Renda
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiLGOEACgkQSIAU/I6SkT1xqQCghYBc12Os3BsskIRYxw3nyKRc
HuUAoIgu5kqrzuS1JfPV0pJjo+Ih5f0l
=78YY
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Aaron Sowry]

rakshat hooja wrote:
>
>
>
> It is already linked from the front page, but clearly from not those
> places it should be from :)
>
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
>
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org
>  etc. 
>
>
> You are right but I think that the problem lies in the fact that 
> Openmoko has not been able to provide any entry point where new people 
> joining the list (after the release of the freerunner) can figure out 
> who and where to ask what question. The Openmoko people are pretty 
> open and if you will ask for something long enough you will get an 
> answer/ access from them. Michael Shiloh of Openmoko used to interface 
> with the community and answer their questions after getting the 
> information from the developers in a regular community update. I think 
> Steve and Michael still do that? Maybe we should have a page on the 
> wiki describing who does what at Openmoko and who to address what 
> question to and also an introductory email for new subscribers listing 
> out similar things.
>
> It has been almost an year since I wrote my first email to Openmoko 
> (actually to Sean  to which Michael Shiloh replied) I can assure you 
> that Openmoko people try their "hardest" to be open and responsive to 
> community suggestions/ questions. But often it takes time for the 
> question/ request to reach the correct person who can answer it / 
> respond to it.
>
> Rakshat
>
>
>
> 
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   
This seems trivial but I think it is important. Even though open-source 
communities often strive to be non-heirarchical it is important that 
there be project leaders and that the people involved with development 
know these people and what their roles are. If you've just come on board 
(like I have) you could almost be forgiven for thinking that the 
Openmoko project is a loose-knit group of enthusiasts casually 
meandering from one platform to the next with no real direction for the 
past 12 months, and I think at least having a visible core team who send 
community updates on a regular basis is a step towards getting everyone 
singing from the same hymn sheet. These and other such details need to 
be prominently displayed on the wiki.

I guess the core aim of Openmoko is to liberate the mobile platform and 
put technology back in the hands of the end-user through open-source 
software, however people are only going to get on board if it works. I 
have to say that I am left slightly underwhelmed after a couple of days 
with my FreeRunner - as a development platform it is brilliant and the 
geek in me certainly doesn't regret the purchase, however it is 
frustrating that after a years worth of open development I am still 
unable to use it as my primary phone (purportedly the main purpose of 
the device) due to hardware and software issues. Remember that Linux is 
set to capture the mobile market in a seriously big way over the next 
few years so we are far from the only ones doing this, and I think that 
if Openmoko is to remain competitive rather than be relegated to a 
hobbyist device then progress needs to be made in leaps and bounds 
rather than dribs and drabs, at least in the usability department. 
Perhaps a little cohesion would be a step in the right direction.

Hopefully this is seen as constructive and not a whiny rant - I figure 
that this mailing list is intended for this type of discussion?


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[rakshat hooja]

>
>
> It is already linked from the front page, but clearly from not those
> places it should be from :)
>
> But you have good points. Openmoko is open, but its development is not
> exposed in the open as much as I'd like for an open source project to
> be. The Openmoko folks are still a bit "mysterious" to me, with the
> exception of the few who regularly post on these mailing lists.
>
> I think the line between Openmoko employee and a contributing, trusted
> community member should be made more fuzzy. More SVN / GIT rights to
> the people, more contributing directly to http://svn.openmoko.org/
> instead of just "external" projects at projects.openmoko.org etc.


You are right but I think that the problem lies in the fact that Openmoko
has not been able to provide any entry point where new people joining the
list (after the release of the freerunner) can figure out who and where to
ask what question. The Openmoko people are pretty open and if you will ask
for something long enough you will get an answer/ access from them.
MichaelShiloh of Openmoko used to interface with the community and
answer their
questions after getting the information from the developers in a regular
community update. I think Steve and Michael still do that? Maybe we should
have a page on the wiki describing who does what at Openmoko and who to
address what question to and also an introductory email for new subscribers
listing out similar things.

It has been almost an year since I wrote my first email to Openmoko
(actually to Sean  to which Michael Shiloh replied) I can assure you that
Openmoko people try their "hardest" to be open and responsive to community
suggestions/ questions. But often it takes time for the question/ request to
reach the correct person who can answer it / respond to it.

Rakshat
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Timo Jyrinki]

2008/7/26 Stroller <[EMAIL PROTECTED]>:
> I won't comment further at this time, but I'll amend the wiki later
> (cc'd to documentation as a reminder) so that some other relevant
> pages link to it & it's easier to find.

It is already linked from the front page, but clearly from not those
places it should be from :)

But you have good points. Openmoko is open, but its development is not
exposed in the open as much as I'd like for an open source project to
be. The Openmoko folks are still a bit "mysterious" to me, with the
exception of the few who regularly post on these mailing lists.

I think the line between Openmoko employee and a contributing, trusted
community member should be made more fuzzy. More SVN / GIT rights to
the people, more contributing directly to http://svn.openmoko.org/
instead of just "external" projects at projects.openmoko.org etc. I
would guess this is going to happen more with the development of FSO?

-Timo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[Stroller]

On 26 Jul 2008, at 09:46, rakshat hooja wrote:
> On Sat, Jul 26, 2008 at 1:16 PM, Stroller  
> <[EMAIL PROTECTED]> wrote:
>
>> There's apparently no design document saying where ASU (or whatever)
>> is going in terms of features. We don't know who to contact in order
>> to get approval for our concepts before we waste a lot of time on
>> them.
>
> I agree with your points and questions and am waiting for answers  
> for Steve but have you seen this
>
> http://wiki.openmoko.org/wiki/ASU_Feature_Plan
>
> It is pretty easy to see the ASU features and who to contact.

Had I seen this? Absolutely not!
And I do wish I had seen it before.

I won't comment further at this time, but I'll amend the wiki later  
(cc'd to documentation as a reminder) so that some other relevant  
pages link to it & it's easier to find.

Stroller.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Community contributions to core apps & features. (Was: Terminal for ASU)

[rakshat hooja]

On Sat, Jul 26, 2008 at 1:16 PM, Stroller <[EMAIL PROTECTED]>wrote:

>
>
> There's apparently no design document saying where ASU (or whatever)
> is going in terms of features. We don't know who to contact in order
> to get approval for our concepts before we waste a lot of time on
> them.


I agree with your points and questions and am waiting for answers for Steve
but have you seen this

http://wiki.openmoko.org/wiki/ASU_Feature_Plan

It is pretty easy to see the ASU features and who to contact.

Rakshat
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Community contributions to core apps & features. (Was: Terminal for ASU)

[Stroller]

On 26 Jul 2008, at 03:10, steve wrote:

> Ask your questions stroller.
>
> I'll  do my best to answer them.

Hi Steve,

Thanks for your reply. I've posted my questions - or rather a request  
for openness & clarification - already in this thread. Because the  
background of the thread already contains all context you ought to  
need, it's difficult to know where to start asking you questions. Let  
me try.

On 21 Jul 2008, at 19:47, Carsten Haitzler (The Rasterman) wrote:
   the problem is the designers decided that ASU is not to have any
   manual keyboard toggle button because it will disturb the design
   and/or confuse users, so all apps and toolkits need modification
   to talk a "protocol" to bring up the keyboard on demand (no manual
   controls). that is why you need to do this.  personally i think you
   need a manual control because, as such, many apps and toolkits will
   not be changed, or they will get it wrong and give you a keyboard
   when you don't want one, or decide not to give you one when you
   do... but that's not my call.

- Who are the designers who decided that ASU is not to have any  
manual keyboard toggle button because it will "disturb the design and/ 
or confuse users" please? Was this a group of Openmoko employees? Or  
a single individual at Openmoko? Does this person have a specified  
role managing the design of ASU? Who do users bitch to if they don't  
like "design decisions"?
- How do you respond to Raster's suggestion that a "manual override"  
will be needed?
- Is a complicated "protocol" to bring up the keyboard on demand -  
which each input method will need to be patched to support - *really*  
better than a simple button?
- Will it be difficult to accommodate this protocol when porting an  
input method (Dasher, for instance) to Openmoko? Or will it be simple  
enough to do so that it easily justifies that lack of a manual  
keyboard button?

No. Ignore those questions.

This is only a small thing. I haven't followed the details of the  
problem closely - it was Raster's "i wanted to do this this way, but  
i wasn't allowed to" that surprised me - but it looks like the  
problems that this introduces aren't unmanageable.

What is of more concern is the connotations of this decision. As far  
as we (end-users on -community) are able to determine, a feature was  
removed by the process of someone @openmoko saying "I don't like  
that" and emailing Raster (or IRCing him or walking into his office)  
and saying "pull that" without saying to the users "hey, before we do  
this, are you using that feature? do *you* think it's ugly or  
confusing?"

Openmoko has always promoted itself as "fully open" - to quote  
Michael's words a couple of days ago:

   the goal of the project is not to create a new cellphone, but rather,
   that by being open, we allow and encourage innovation, and that by
   working with you, the open source community, we tap into a huge
   pool of imaginative, creative, very smart and hardworking innovators.

I have always understood Openmoko's openness to encompass the *entire  
breadth* of Openmoko software development. It's great if we can write  
apps for the Freerunner, but I can already write apps for Symbian or  
Windows Mobile. It's great that I can fork the code Openmoko are  
writing commercially and make modifications to the application  
manager or the dialler but that's obviously a duplication of effort -  
I thought you wanted the community to help contribute to the core  
applications, too. Isn't this the case?

Let's talk about the hypothetical community member Bob. Bob has a  
great idea a feature that he'd like to see on his mobile phone. Let's  
say he's meeting Charlie at cafe near the Linux convention and he  
thinks "it'd be great if I could select Charlie in my phone's  
addressbook and - alongside 'call contact' and 'SMS contact' - it  
said 'Send my location'. I'd just click that and it could SMS my GPS  
location to Charlie and on Charlie's phone it would pop up a message  
'Bob has sent you his location by SMS. Would you like to see where he  
is?' and then show a map with my location on it (or at least a needle  
showing distance and direction)".

Under a normal community development process Bob has some idea of  
whether or not other developers might like this idea. He can message  
them on IRC and say "would you include that in the main tree?" Bob  
can hack together a bit of code showing a working prototype and post  
patches to the mailing list knowing that the community will at least  
consider it. They might say "cool idea, but no-one'll use it, so we  
don't want it in the core distro", they might say "it needs a lot of  
polish", they might say "add a configuration option to enable/disable  
it". But even if they ultimately reject it, Bob can submit his code  
with some idea of the shared goals of the other developers and  
knowing that the idea will be considered on the merits of whether the  
other developers t