Project Status Wiki?

[Kev Latimer]

On 27/04/2012 01:27, Brad Hards wrote:
> 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.
I think it's an excellent idea too.  There's an awful lot of "suck it 
and see" at the moment (not to decry the efforts of everyone - the pace 
of the project is quite incredible) but quite often you just don't know 
if a feature works until you build and test it yourself.
>
>> 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
I think there's a middle ground approach here?  I've not seen Enzyme or 
KDE development but I do like the idea quite a lot.   I think if someone 
with a good knowledge of the Samba4 project and it's goals is able to 
create a hierarchy as Charles suggests, as a starting point, is there 
any reason why we can't take the commit-digest approach as a community 
from there on in?  I think one thing Charles is getting at is that we 
(the Royal we!), as sysadmin's, managers etc. (ie. not developers or 
programmers) aren't in as good a position to comment on the code and 
therefore it's effects but, as Brad eludes to, is there anything 
stopping some of us taking "ownership" of a particular feature we have 
an interest in and reporting on it's progress?  Charles with domain 
trusts, I'm particularly interested in DRS and replicating DNS, I'm sure 
other people have interests in the file server, LDAP interface etc. so I 
don't think we'd have a shortage of volunteers?  After all, we have the 
commit logs and we're running the software so it's not especially 
difficult to snapshot an environment, build the latest git and report on 
how well your favourite toy plays.  As responsible sysadmins, surely we 
should be doing that level of testing anyway... :-)  As long as the 
mailing list continues as an interface with the devs for the occasional 
stupid question from one of the project feature "trackers" I don't see 
why we couldn't take a community approach to demonstrating the status 
and maturity of Samba4?  Am I on the right track?

Cheers,

Kev

-- 
Kev