(2012/09/22 10:02), Christopher Browne wrote:
>
> If the present project is having a tough time doing enhancements, I
> should think it mighty questionable to try to draw it into core, that
> presses it towards a group of already very busy developers.
>
> On the other hand, if the present development efforts can be made more
> public, by having them take place in a more public repository, that at
> least has potential to let others in the community see and
> participate. There are no guarantees, but privacy is liable to hurt.
>
> I wouldn't expect any sudden huge influx of developers, but a steady
> visible stream of development effort would be mighty useful to a
> "merge into core" argument.
>
> A *lot* of projects are a lot like this. On the Slony project, we
> have tried hard to maintain this sort of visibility. Steve Singer,
> Jan Wieck and I do our individual efforts on git repos visible at
> GitHub to ensure ongoing efforts aren't invisible inside a corporate
> repo. It hasn't led to any massive of extra developers, but I am
> always grateful to see Peter Eisentraut's bug reports.
>
Agreed. What reorg project needs first is transparency, including
issue traking, bugs, listup todo items, clearfied release schedules,
quarity assurance and so force.
Only after all that done, the discussion to put them to core can be started.
Until now, reorg is developed and maintained behind corporate repository.
But now that its activity goes slow, what I should do as a maintainer is to
try development process more public and finds someone to corporate with:)
Sakamoto
