Re: Proposal for Seahorse inclusion in GNOME 2.18

[Nate Nielsen]

Wouter Bolsterlee wrote:
> På Sat, Sep 09, 2006 at 10:04:09PM +, Nate Nielsen skrev:
>> Key Manager
>>   * gnome-keyring integration for GnuPG and OpenSSH
> 
> As an outsider I'm wondering: would a merge with gnome-keyring itself
> instead of building on top of it be a good idea?

The underlying concepts and technologies of gnome-keyring (which really
should be 'gnome-password') and encryption keys are extremely different.

That said, presenting them to the user in a common UI may be an idea
worth pursuing.

Nate Nielsen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for Seahorse inclusion in GNOME 2.18

[Wouter Bolsterlee]

På Sat, Sep 09, 2006 at 10:04:09PM +, Nate Nielsen skrev:
> Key Manager
>   * gnome-keyring integration for GnuPG and OpenSSH

As an outsider I'm wondering: would a merge with gnome-keyring itself
instead of building on top of it be a good idea?

  mvrgr, Wouter

-- 
:wq   mail [EMAIL PROTECTED]
  web http://uwstopia.nl

you gotta hold on to something you believe   -- electric light orchestra


signature.asc
Description: Digital signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nine Months in Six Months

[Matthew Paul Thomas]

On Sep 10, 2006, at 8:31 AM, Nickolay V. Shmyrev wrote:
> ...
> [Shaun McCance wrote:]
>>
>> But now you want all these programmers to assemble their 
>> documentation piecemeal as they add features?
>>
>> Even if they all had perfect English (which they don't), and even if 
>> they were all really good at explaining things (which they aren't), 
>> this would still produce bad documentation.  Why?  Because it would 
>> only ever produce "What's this?" documents, and never "How do I?" 
>> documents.
>>
>> I find myself shooting down this idea every single release cycle.
> ...

I humbly suggest that as long as you keep shooting it down, you will 
keep having the problem of not enough time to write "documentation".

Calling it "documentation" almost enforces the problem, suggesting that 
you're documenting something that has already been written. But just as 
with the interaction design, and just as with the test suite, you'll 
often get better results if the help for a feature is written before 
the code. The goal of all these disciplines is to maximize the 
proportion of people who use the software successfully, and it makes 
little sense to treat any of them as completely separate from the 
others.

I haven't seen anyone claim that programmers are usually good at 
writing help; it would be surprising if they were. But whenever they're 
not, they should team up with someone who is. Just as they should team 
up with someone good at interaction design, and someone good at 
thinking up test cases. For each module in Gnome (as I said on 
gnome-doc-list last month), you should be able to ask, "who is the 
maintainer, who is the interaction designer, who is the QA engineer, 
and who is the help author", and get three or four distinct answers.

> ...
> Agree, it's really a problem, but look at usability guys, they all just
> do a review, interface is created by developers. Developers are
> certainly not professional UI designers but HIG shows them the correct
> direction. It's much easier to review something and correct mistakes
> then to write it from scratch.
> ...

That is very far from the truth. It is much, much easier to correct 
usability mistakes before the code has been written than after.


As for the HIGs, they mostly specify style for low-level things like 
appropriate window types, controls, spacing, and wording. Not having to 
constantly debate those things can save people a lot of time. But they 
are only a small part of design; they don't address fundamental design 
problems. (The most common such problem: "This shouldn't be a separate 
program, it should be a menu item in program X".) No book of guidelines 
can turn a musician into a composer, a surgeon into a medical 
researcher, or a programmer into an interaction designer.

-- 
Matthew Paul Thomas
http://mpt.net.nz/

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Proposal for Seahorse inclusion in GNOME 2.18

[Nate Nielsen]

Seahorse is a encryption key manager for GNOME. It currently 'manages'
PGP and SSH keys (work has been done on X.509 certificates [1]).

The Seahorse developers would like to propose Seahorse 0.9.x for
inclusion in GNOME. It offers:

libcryptui
  * An API for querying the keys on the system, searching key servers,
widgets to select keys.
  * D-Bus based.

Key Manager
  * Creation of SSH keys and GPG keys
  * Configuration of keys, import, export etc..
  * The interface and concepts for users are getting simpler
and clearer with each release.
  * gnome-keyring integration for GnuPG and OpenSSH
  * HKP and LDAP key server integration
  * SSH key authorization and upload

Plugins
  * File encryption (nautilus plugin)
  * Text encryption (gedit plugin)
  * A panel-applet for those with special clipboard encryption needs.

Other
  * Rendezvous based key sharing to share a pool of keys on a network

The Seahorse developers' long term goal is to make encryption easy to
use within GNOME. Besides filling a need for a key manager, inclusion in
GNOME would help us realize that goal. For example:

  * EDS Address book integration
  * About-me: 'my' encryption key selection
  * More intelligent trust metrics based on frequency of use

Suggestions for how Seahorse can improve are welcome, as are ideas for
making encryption easier for users. Taking a look at a recent seahorse
release will help your comments that much more insightful:

http://ftp.gnome.org/pub/GNOME/sources/seahorse/0.9/seahorse-0.9.4.tar.gz

Cheers,
Nate Nielsen


[1] http://bugzilla.gnome.org/show_bug.cgi?id=351858

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nine Months in Six Months

[Nickolay V. Shmyrev]

> 
> You'll notice one of the new things in my proposal
> was the idea of a string review.  There are a lot
> of crappy strings in our interfaces, often because
> many of our programmers just don't have very good
> English skills.
> 
> And that's fine.  Hey, my German pretty much sucks,
> although I can get by with it.  I can't expect the
> world to have perfect English.  So we'll do some
> string reviews instead, where we can fix problems.
> 
> But now you want all these programmers to assemble
> their documentation piecemeal as they add features?
> 
> Even if they all had perfect English (which they
> don't), and even if they were all really good at
> explaining things (which they aren't), this would
> still produce bad documentation.  Why?  Because it
> would only ever produce "What's this?" documents,
> and never "How do I?" documents.
> 
> I find myself shooting down this idea every single
> release cycle.
> 
> --
> Shaun
> 
> 

Agree, it's really a problem, but look at usability guys, they all just
do a review, interface is created by developers. Developers are
certainly not professional UI designers but HIG shows them the correct
direction. It's much easier to review something and correct mistakes
then to write it from scratch.

Gustavo's point about rising entrance barrier is also a good objection,
but let me disagree that code is more important than docs. Moreover I
think we should encourage newbies to write some docs, this way they will
understand application and feature use cases, they will clear the vision
of application behavior. Code is a minor thing we know, people make
project better ;)

But documentation is a minor thing, correct design decisions are much
more important, documentation was the first item in the list, but I push
roadmap policy and proposal policy more. Do we need cross-platform GNOME
or not, do we provide complete development platform with stuff for
collaboration, advanced messaging and networking or just an advanced UI
library..

Heh, my German is even more worse, but I hope you'll get an idea.



signature.asc
Description: Эта часть	 сообщения	 подписана	 цифровой	 подписью
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nine Months in Six Months

[Shaun McCance]

On Sat, 2006-09-09 at 09:41 +0400, Nickolay V. Shmyrev wrote:
> В Сбт, 09/09/2006 в 04:55 +0200, BJörn Lindqvist пишет:
> > On 9/8/06, Don Scorgie <[EMAIL PROTECTED]> wrote:
> > > Doc people do not have enough time.  Its as simple as that.  As shaunm
> > > pointed out, this release we got 4 weeks to update the documentation.
> > > This included 3 new modules needing docs, as well as lots of updates to
> > > lots of other docs.  The doc team has been on skeleton staff ever since
> > > I've known it.  Most of the docs are now pretty out of date.  Add in a
> > > desire to have translated docs and basically, the doc team has negative
> > > time to do the required work.  The great part about it is that for the
> > > other 5 months, the doc team is pretty much sitting around, twiddling
> > > thumbs and thinking up plans for world domination [1].  The writers
> > > can't really do their thing with a moving target.
> > 
> > Then lets stop the target! If I understand you correctly, the
> > development process from the documentors point of view is kind of like
> > this.
> > 
> > * Five months were developers play and pretty much destroy all the docs we 
> > make.
> > * Four weeks were we can undo the damage caused and make GNOME 
> > understandable.
> > 
> > Maybe this problem can be solved by elevating the documentations and
> > the translations status in the project? For example, patches are very
> > seldom accepted if they introduce regressions in the software. But
> > regressions in the docs aren't counted in the same way. New code very
> > often changes applications behaviour so that the manual becomes
> > invalid. What if the documentation and translation regressions were
> > counted in the same way as code regressions?
> > 
> > To me, that makes sense. An untranslated string is just as annoying as
> > a frequently segfaulting program. So lets treat the problems the same.
> > Code that changes behaviour shouldn't be committed unless the
> > documentation is updated. User visible strings shouldn't be changed
> > unless the translations are updated. Something like that?
> > 
> 
> Exactly, and although it's a not reasonable to wait for translations
> update as Adam pointed, C locale documentation should be updated by
> change author. As for translations we don't have much problem with them
> now, when we support more than 40 languages.

You'll notice one of the new things in my proposal
was the idea of a string review.  There are a lot
of crappy strings in our interfaces, often because
many of our programmers just don't have very good
English skills.

And that's fine.  Hey, my German pretty much sucks,
although I can get by with it.  I can't expect the
world to have perfect English.  So we'll do some
string reviews instead, where we can fix problems.

But now you want all these programmers to assemble
their documentation piecemeal as they add features?

Even if they all had perfect English (which they
don't), and even if they were all really good at
explaining things (which they aren't), this would
still produce bad documentation.  Why?  Because it
would only ever produce "What's this?" documents,
and never "How do I?" documents.

I find myself shooting down this idea every single
release cycle.

--
Shaun


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nine Months in Six Months

[Alan Horkan]

On Sat, 9 Sep 2006, [ISO-8859-1] BJörn Lindqvist wrote:

[...]

> * Five months were developers play and pretty much destroy all the docs we 
> make.
> * Four weeks were we can undo the damage caused and make GNOME understandable.
>
> Maybe this problem can be solved by elevating the documentations and
> the translations status in the project? For example, patches are very
> seldom accepted if they introduce regressions in the software. But
> regressions in the docs aren't counted in the same way. New code very
> often changes applications behaviour so that the manual becomes
> invalid. What if the documentation and translation regressions were
> counted in the same way as code regressions?

> To me, that makes sense. An untranslated string is just as annoying as
> a frequently segfaulting program. So lets treat the problems the same.
> Code that changes behaviour shouldn't be committed unless the
> documentation is updated.

This can be mildly annoying but it is one of those things you know you
should do.  If the documentation is hard to write is often a strong
indication that the new feature is hard to use and the design might need
to be improved.  I have a lot of respect for Gnome Games which had a
policy of requiring basic documentation with new Aisleriot changes.  The
task made easier by the fact that most of the new documentation was really
a variation on what was already there.  Callum was nice about and
civilised about the requirement for documentation which is important
because documentation we wouldn't be hurdle or barrier to contribution.

It would be great if the documentation team could be elevated to the
status of documentation editors who would help review improve the rough
descriptions provided rather than having to write from scratch.

-- 
Alan H.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Nine Months in Six Months

[Gustavo J. A. M. Carneiro]

Sáb, 2006-09-09 às 04:55 +0200, BJörn Lindqvist escreveu:
> On 9/8/06, Don Scorgie <[EMAIL PROTECTED]> wrote:
> > Doc people do not have enough time.  Its as simple as that.  As shaunm
> > pointed out, this release we got 4 weeks to update the documentation.
> > This included 3 new modules needing docs, as well as lots of updates to
> > lots of other docs.  The doc team has been on skeleton staff ever since
> > I've known it.  Most of the docs are now pretty out of date.  Add in a
> > desire to have translated docs and basically, the doc team has negative
> > time to do the required work.  The great part about it is that for the
> > other 5 months, the doc team is pretty much sitting around, twiddling
> > thumbs and thinking up plans for world domination [1].  The writers
> > can't really do their thing with a moving target.
> 
> Then lets stop the target! If I understand you correctly, the
> development process from the documentors point of view is kind of like
> this.
> 
> * Five months were developers play and pretty much destroy all the docs we 
> make.
> * Four weeks were we can undo the damage caused and make GNOME understandable.
> 
> Maybe this problem can be solved by elevating the documentations and
> the translations status in the project? For example, patches are very
> seldom accepted if they introduce regressions in the software. But
> regressions in the docs aren't counted in the same way. New code very
> often changes applications behaviour so that the manual becomes
> invalid. What if the documentation and translation regressions were
> counted in the same way as code regressions?
> 
> To me, that makes sense. An untranslated string is just as annoying as
> a frequently segfaulting program. So lets treat the problems the same.
> Code that changes behaviour shouldn't be committed unless the
> documentation is updated. User visible strings shouldn't be changed
> unless the translations are updated. Something like that?

  1. Code truly is more important than documentation, that's why it's
treated more importantly;

  2. If you raise the bar for accepting contributions, making
contributors update documentation at the same time, you'll surely have
less contributions;

  3. Documention doesn't destabilize the program, it can go on for a
much longer time after code/feature freeze.  If you want to delay the
official GNOME .0 release for documentation, that's another matter.  But
delaying or forbidding contributions because of lack documentation is
unthinkable.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list