bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: Incubator PMC/Board report for Dec 2012 ([ppmc])
Date Tue, 04 Dec 2012 16:59:35 GMT
On 04/12/12 14:29, Olemis Lang wrote:
> On 12/4/12, Gary Martin <> wrote:
>> On 03/12/12 22:54, Olemis Lang wrote:
>> I suppose we could have a
>> section in the wiki for upcoming documentation or the documentation of
>> upcoming features.
> Interesting . Maybe that's what BEP are for , but if there is a need
> for something different than that , I think it's ok .

Well, there is certainly a distinction when considering user docs. If 
you want to refactor the information into a BEP then that is probably 
fine too.
>>> 2. mention the work we started on BEPs as a means to gather
>>>       community consensus and eventually also being a reference,
>>>       and documentation of major changes .
>> So to meet this suggestion I could append something like the following
>> to the final paragraph:
>> Along these lines, the project has added a number of enhancement proposal
>> pages to the wiki that are intended to reflect the decisions made on the
>> project's dev mailing list, reducing the need to be aware of all previous
>> discussion for newcomers.
> "One such proposal documents how the community will work on tickets
> submitted to the issue tracker. As a consequence in a few minutes new
> contributors will understand our workflow and the reasons we
> considered to install it ."
> ... more or less ... please improve .
> ;)

OK, thanks for the suggestion. I attempted to embed it within the 
paragraph rather than tack it on at the end. It might not be any better 
of course. Anyway, I attempted to keep my mention of infrastructure 
neutral to avoid offsetting the attempts to show a little more optimism 
(talk of successful release and the smoother process for 0.3.0, dropping 
the explicit suggestion that there is more to improve in documentation 
to help new contributors..) and here is my new suggestion:

Since the last report, Bloodhound has successfully created two more releases.
The problems highlighted in the September report, regarding the use of an
external site for the download of some of the dependencies, have been largely
solved by working with their maintainers to ensure that their packages are
available through a standard location (pypi).

Releases themselves are beginning to become a little more routine although the
time between the initiation of the vote for release of 0.2.0 and the subsequent
announcement of the result was of concern but the 0.3.0 release was
significantly smoother.

Three new committers have been added to the project and they have driven
considerable conversation on the mailing lists in a relatively short time. The
barriers to contributing have been reduced significantly and we plan to
continue to work on this area. In addition to the identification of tickets
that are suitable for newcomers we now have documentation of aspects of ticket
management and the workflow that we use. Proposals for larger enhancements are
also documented on the wiki in such a way that they reflect the decisions made
on the project dev mailing list, reducing the work associated with digging
through the mailing list.

 From the infrastructure side the project has two open requests. One of these
requests was opened in July, requesting a means for the Bloodhound source
browser to have effective access to a local copy of the svn repository.
Alternatives have been suggested but there is no obvious resolution to this
issue at this point.

So, if we drop the establishment of a frequent release cycle from the 
list of the top three issues, I could add Grow User Community in the 
second position if that seems distinct enough. Other suggestions are 


View raw message