Project Status Wiki?

[Brad Hards]

On Friday 27 April 2012 04:22:15 Charles Tryon wrote:
> Failing that, I am thinking of starting another Wiki page.  This is NOT
> intended to be a deep, "bugzilla" level tracking of sub projects, but more
> something a technical manager (like, my boss) could look at quickly, nod
> his or her head and say, "I've got a comfort level about the features that
> are important to me." 
I can understand why this is important.

> Since I'm not the one overseeing these features, or
> even working on them, individual developers would need to remember to add
> their own projects, and occasionally take a look at the page to make
> updates as their projects mature.
I think this is the reason why your idea won't work. 

The problem is "important to me (the user/admin)" and "features (to a 
programmer)" aren't even measured in the same way. 

> Hopefully, this will reduce the number
> of posts asking things like, "I'm trying to get printing working.  Does
> Samba4 support printing yet??"
Developers don't think in those terms. That is a project manager view of the 
world. An admin might think in terms of "does the remote printer management 
service tool currently handle setting ACLs (or whatever)". The developer think 
more in RPC call parameters.

As an example, see http://wiki.samba.org/index.php/Samba4_DRS_TODO_List
 (which is not up-to-date, even though it was created by a couple of the 
Samba4 developers).

> The table would contain columns something like this:
> 
> Feature:
>   A short name of the feature or project.  There might be some overlap, and
> there would certainly need to be some way to create simple hierarchies.
>  This could be a name of an interface or AD feature.  The temptation would
> be to break things down TOO much, but that would just make it harder to
> maintain.  "SIMPLE" is key here.
(snip).
"SIMPLE" for who?
> The last thing I want to do is create more Project Management overhead! 
I think you are asking for more management overhead (its something else to 
update, so it has to be, at least a bit).

I've got another idea though - one that doesn't involve developers updating 
wiki pages.
1. Find a couple of people who currently aren't involved in detail 
development.
2. Identify the way you want features to be identified / reported / summarised 
(like the list that you provided and I snipped above)
3. Watch the commit messages - identify when something important might have 
changed.
4. Test the new code (from git) and provide feedback to developers (e.g. by 
mail or IRC) as appropriate.
5. Convert the test results back into the right format for the summary page.

This would actually help to get Samba4 done, and wouldn't add any work for the 
(all too few) developers. Steps 1-3 are done by other projects (e.g. KDE has a 
http://commit-digest.org/ for people who summarise weekly commits, and the 
not-KDE-specific tool that runs under it is FOSS - http://enzyme-project.org/).

I could be wrong here - I certainly don't speak for those doing the work, and 
there are so few developers you might be able to convince them that this is 
worth doing. 

Again, I'm not saying that it wouldn't be a good thing to have, only that 
asking developers to do it isn't going to get you the information that you 
want, and might actually slow down development instead.

Brad