headers
Gary Cunningham-Lee | 1 Feb 2009 11:02
Favicon
Gravatar

Advanced search form

In trunk, the small "help" button in the search form is adequate to get 
the help info, it seems. Can the large red help icon not appear until 
the small help button is clicked? The big icon is really overkill, 
especially since it follows scrolling down the page, leaving the search 
form behind.

Having more search options is great, but the search form is getting 
pretty big (stretches more than halfway across a 1024px display). Is it 
possible to have a really simple and compact search input that expands 
when "advanced search" is clicked or hovered over? Maybe the help info 
could even be included in this expanded space to eliminate the need for 
the separate side popout. (The present info is pretty verbose, too, and 
could be shortened to fit in a smaller area.)

-- Gary

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Permalink | Reply | 2 comments |
headers
Marc Laporte | 1 Feb 2009 13:00
Gravatar

The Antonio Pizzigati Prize for Software in the Public Interest

fyi

---------- Forwarded message ----------
From: The Antonio Pizzigati Prize for Software in the Public Interest
Date: Sat, Jan 31, 2009 at 9:52 PM
Subject: 3rd Annual Pizzigatti Prize Arard for 2009

2009 Application Acceptance Open

Pizzigati Prize 2009 competition

Good deeds do get rewarded! If you know someone who's been toiling in
the open source vineyards, developing software that's helping
nonprofits succeed, check out the Tides Foundation Pizzigati Prize, a
$10,000 annual award for outstanding contributions to software in the
public interest. The competition, judged by a panel of national
leaders in public interest computing, is now entering its third year.
The application deadline for this year's prize: March 2nd, 2009.

You can find out more in our Prize Information section of this website.

Our 2009 Application Deadline

Application materials for the 2009 Pizzigati Prize competition will be
posted iin January. Our 2009 application deadline will be March 2.
2009

--

-- 
Marc Laporte
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Laporte | 1 Feb 2009 15:39
Gravatar

Re: [Tikiwiki-cvs/svn] SF.net SVN: tikiwiki:[15091] trunk

Hi!

There are 25 (!) permissions that can be globally assigned to wiki
pages. Each of these permissions was added to solve a real world
problem. This is fined-grained, powerful, flexible and amazing.

Now, these 25 perms are available automatically to each wiki page.
Some (tiki_p_watch_structure, tiki_p_edit_structures), I question if
it's even logical to show on the wiki page object permission page.
Maybe they should be on the structure page and they are just here by
accident because structures are so closely linked to the wiki.

Now, for anybody that tried to teach users about assigning individual
permissions to a wiki page has seen how difficult it is for new users.
A quick fix was to restrict the possibility to assign perms for
features that are off while still maintaining the possibility of
deleting those assigned perms even after the feature is turned off.

Now, while this helps, it's still difficult for users. In that ideal
world that I dream of, it's possible to add an order to the
permissions. So we could put the most important ones at the top.
view, edit and history and hide stuff like tiki_p_watch_structure and
tiki_p_edit_dynvar at the bottom. This doesn't have to be an admin
setting. If you just tell me where to fix this in the code, I can set
a better ordering.

Even more wonderful would be to have basic vs advanced perms and have
this configurable in the admin panel and thus, distributable as
profiles. The "basicness"  [ hey, I think I invented a word! :-) ] or
not of perm really depends on the use case.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Laporte | 1 Feb 2009 19:03
Gravatar

Re: Disengagement letter

Hello,

About 6 months ago, at the TikiFest in Strasbourg, there was a
discussion on how we could improve our code peer review process. There
are a lot of commits, and we have a good number of people monitoring
the CVS mailing list.
https://lists.sourceforge.net/lists/listinfo/tikiwiki-cvs

However, we don't know if 20 people reviewed a particular commit and
another was forgotten. We have no formal feedback mechanism.

The idea was brought up to have some sort of web-based review system,
where developers could quickly mark commits as they are checked. We
could be more systematic about making sure all commits are peer
reviewed and it would make us more scaleable/efficient/distributed. I
understand that Nyloth has been reviewing every single commit for a
long long time now. That is a LOT of commits!

Anyway, the idea resurfaced recently. If Tiki was a better tool for
software project management (both in reality and in perception), we
would no doubt indirectly attract more software developers. As an
example, Trac has nearly a 1000 stacks on Ohloh:
https://www.ohloh.net/p/trac

My guess is that they have more developers that they know what to do with :-)

And here is how Louis-Philippe was thinking about (and started
addressing) the challenge.
http://blog.lphuberdeau.com/wordpress/2009/01/25/adding-collaboration-and-durability-to-code-reviews/
(Continue reading)

Permalink | Reply | 29 comments |
headers
Jean-Marc Libs | 1 Feb 2009 22:11
Picon

Re: Bye

On Sat, Jan 31, 2009 at 4:30 PM, Sylvie Greverend
<sgreverend@...> wrote:
> 1) I do not want trunk to be full of bugs - I do not want the risk to
> have people thinking 3.0 is a regression.
> 2) I am upset because there is no way to have technical discussion. If I
> would have been the only one, I would have let go. I can be wrong.
> Marc said: 'Having top contributors treated this way is totally
> unacceptable.' What does it mean? If I want to be sure we are not wrong
> about a technical choice, my doubt is unacceptable because the  choice
> was done by an untouchable.
> Sorry, this is wrong.
> But ... I need to take some distance and not be so attached to tikiwiki.
> So I agree to merge the ui-revamp branch in trunk now.
> It is a sunny day here.
> Sylvie

I've been reflecting on the process which led Louis-Philippe to write
his Disengagement Letter. I feel the way we have organised tikiwiki's
development process puts too much strain on our developpers, as
evidenced by the high burnout rate. Sylvie's mail just reinforces my
viewpoint.

In July, during the Strasbourg TikiFest, after much debate, we decided
that we would have nearly everything everybody present wanted:
* calendar releases
* a stable, bug-free version available for download
* a dev version suitable for use at any time
* the possibility to add major improvements through branches which are
merged afterwards
(Continue reading)

Permalink | Reply | 2 comments |
headers
Scot Wilcoxon | 1 Feb 2009 23:19
Favicon

Re: version processing (was: Bye)

> In July, during the Strasbourg TikiFest, after much debate, we decided
> that we would have nearly everything everybody present wanted:
> * calendar releases
> * a stable, bug-free version available for download
> * a dev version suitable for use at any time
> * the possibility to add major improvements through branches which are
> merged afterwards

It's the first time I heard of this list.  Where is this documented on
dev.tw.o?  Where are the procedures on how to do these things?

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Permalink | Reply | 1 comment |
headers
Marc Laporte | 2 Feb 2009 02:37
Gravatar

Re: version processing (was: Bye)

http://dev.tikiwiki.org/RoadMap
http://dev.tikiwiki.org/Where+to+commit

On Sun, Feb 1, 2009 at 11:19 PM, Scot Wilcoxon <scot@...> wrote:
>> In July, during the Strasbourg TikiFest, after much debate, we decided
>> that we would have nearly everything everybody present wanted:
>> * calendar releases
>> * a stable, bug-free version available for download
>> * a dev version suitable for use at any time
>> * the possibility to add major improvements through branches which are
>> merged afterwards
>
> It's the first time I heard of this list.  Where is this documented on
> dev.tw.o?  Where are the procedures on how to do these things?
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Tikiwiki-devel mailing list
> Tikiwiki-devel@...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>

--

-- 
Marc Laporte
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Laporte | 2 Feb 2009 06:21
Gravatar

Question/discussion about "Where to Commit" guidelines

Hi Jean-Marc,

Thank you for thinking about this and bringing it up.

I take this opportunity to share my thoughts on the guidelines that
emerged from the discussions in Strasbourg last year:
http://dev.tikiwiki.org/RoadMap
http://dev.tikiwiki.org/Where+to+commit
http://tikiwiki.org/TikiFestStrasbourg

About "we decided that we would have nearly everything everybody
present wanted". I think this is what often happens when we look at
what we want and that we don't have (or choose not to) to look at "how
much it costs". What we are trying to balance is the conflicting needs
of stability and innovation. I think an important underlying debate
is: what is our tolerance to regressions?

In general, I think they (the new guidelines) are a tremendous step
forward. The most important thing, by far, IMO, is a calendar release.
We have to stay away from anything that will make it possible to go on
for much too long between releases, like we did between 1.9.x and 2.x
  The time span and dates are up for debate but we have to have a
predictable release schedule. This focuses everyone on a goal and
brings clarity.

A calendar release, even for innovation, is a form of predictability.
Even though I am guilty of wanting-everything-all-the-time, this
roadmap has made me ponder and push back some of my goals to version 4
and 5.
(Continue reading)

Permalink | Reply | 668 comments |
headers
Marc Laporte | 2 Feb 2009 07:07
Gravatar

Re: Question/discussion about "Where to Commit" guidelines

Hi again,

I also have no specific proposal. Just some questions and thoughts.

1 and 3 are indeed a balancing act. However, I feel that 3 and 4 are
in a struggle as well. Things tend to only get stable when merged into
trunk. And this causes at least temporary instability.

I'd like to touch more on innovation.

With the current setup, it was possible to add massive innovations for
totally new features (like Profiles). We don't have to worry about
regression probability or affecting an existing user base. Profiles
were started in version 2.0, but as a hidden feature. (It's started in
the 2.x package but there is no link anywhere). This was in trunk long
before reaching a releasable-at-any-time state, yet self-contained.
This is good. It would have been annoying to have had to setup an
experimental branch for this.

Perhaps we should factor in how far away to the release we are for
making important changes. I think we somewhat do it intuitively, but
maybe this should be part of the guidelines. So major transversal
changes should be done early in the cycle. But of course, this is more
slippery slope, because it could take trunk below the usable-level
threshold... On the other hand, those wanting stability may be content
with the just-released version.

I look forward to reading your thoughts on all this.

Best regards,
(Continue reading)

Permalink | Reply | 1 comment |
headers
luci aka luciash d' being | 2 Feb 2009 09:32
Picon
Favicon
Gravatar

Re: Put me to work!

hi,
welcome back dave :)

i think we need lot of current screenshots of usage and administration 
of tiki to be added/replaced on the doc.tw.o.

luci

On 31/01/09 17:37, Dave Thacker wrote:
> As of today, I'm officially back at work on Tikiwiki.  I have missed this 
> project dearly over the last eight months, and I'm looking forward to 
> resuming my role of testing, documentation, bug hunting, and shouting 
> encouragement.  
> I'm saddened by the tone of the mailing list the past few days.  I know that 
> our developers are passionate about tiki, and great passion sometimes leads 
> to great frustration, to the point of walking away.  Please don't, we need 
> you all!   I encourage everyone who feels that frustrated to take a break and 
> come back with a new perspective.   Just don't stay away as long as I did!
>
> So what needs documenting or testing the most?  
>
> Dave Thacker
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |

Gmane