On 04/12/12 14:29, Olemis Lang wrote:
On 12/4/12, Gary Martin <[email protected]> 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
welcome.
Cheers,
Gary
