Project Status Wiki?

[Charles Tryon]

Hi Brad!

Well, my intent is to get people thinking about this, not to say you have
to do it one particular way or another, so I'm open to lots of different
ideas!

On Thu, Apr 26, 2012 at 8:27 PM, Brad Hards <bradh at frogmouth.net> 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.
>
> > 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.
>

After doing software development for 30+ years, I've come to realize that,
while most developers (myself included) view "project management" as
useless overhead getting in the way of their REAL WORK, it
is unfortunately, the magical thing which transforms a developer's
"interesting project" into something that people can actually use in a real
production environment.  The encouraging thing is that we're seeing more
and more people (non-developers) on this list who really ARE trying to use
Samba4 to do useful work!  The tricky part is finding a way to do "Project
Management" (read: "communication", not "control"!) in a way that benefits
people who are trying to USE the software, without getting in the way of
the people trying to BUILD the software.

You're right though that developers and administrators/users think about
features from very different vantage points, which makes it difficult for
developers to even know how to report "status" in a way that is meaningful
to a network admin.  I'm just trying to figure out SOMETHING to start the
communication.



> 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 that using commit messages is a good idea, as long as developers
actually put useful content into these messages!  Unfortunately, I've spent
too many years reading SCCS/RCS/Subversion/git commit logs that read like,
"fixing glitches". :-(  Assuming that real, useful comments exist, do you
map commits to features by the author, the source code module, the date,
the commit ID?  Suggestions?

  Any other people interested in tracking their "important" features would
be welcome.


  (I'm working on learning my way around Git.  Any expert suggestions on
how to get this information would be most appreciated!)

-- 
    Charles Tryon
_________________________________________________________________________
  “Risks are not to be evaluated in terms of the probability of success,
but in terms of the value of the goal.”
                - Ralph D. Winter