On 2/11/14, 6:34 AM, Dicebot wrote:
> On Tuesday, 11 February 2014 at 02:29:49 UTC, Andrei Alexandrescu wrote:
>> Same difference. A bunch of people can pull, I'm hardly the
>> bottleneck. It just means I failed to convince the community to get
>> those bounties done.
>>
>> Andrei
>
> Still that list (people with pull rights) is relatively short so it does
> not make much sense to appeal to wider auditory.
>
> Also I don't think volunteer effort can't be organized. It is a matter
> of people identifying themselves as part of well-defined organization as
> opposed to independent crowd of collaborators.

I think we could organize ourselves better, too. It's all a matter of finding the right angle. But I think management is not what we need. We need better leadership. Big difference.

> It is a common wisdom
> that if no one feels directly responsible for an issue, no one will ever
> pay attention to it.

Yah, on the trite side even I'd opine :o). I said this several times now, and I'll say it again: I have asked SEVERAL TIMES people INDIVIDUALLY to do things that are HIGH IMPACT for the D language instead of something else that was more important to them, to no avail.

Of course, it would be learned helplessness to draw sweeping conclusions from the experience so far.

> Do you need any specific proposals?

Suggestions for doing things better are gladly considered.


Andrei

11-Feb-2014 21:12, Andrei Alexandrescu пишет:
> On 2/11/14, 6:34 AM, Dicebot wrote:
>> Do you need any specific proposals?
>
> Suggestions for doing things better are gladly considered.
>

I'd risk suggesting introducing something simple and self-organizable.
To be concrete: define "interest groups" by major areas of D ecosystem (Fronted, one for each backend, druntime as a whole, GC alone, Phobos in bits and pieces ...)  and let people join/leave/lead these.

At the very least it would make it obvious who is into what at which point of time. Even more importantly - who you'd need to ask about what.

The only question is where to track this stuff - maybe Wiki?

P.S. Trello was a failed experiment, but IMHO it failed largely due to being behind the closed doors.

-- 
Dmitry Olshansky

On 2/11/14, 9:27 AM, Dmitry Olshansky wrote:
> 11-Feb-2014 21:12, Andrei Alexandrescu пишет:
>> On 2/11/14, 6:34 AM, Dicebot wrote:
>>> Do you need any specific proposals?
>>
>> Suggestions for doing things better are gladly considered.
>>
>
> I'd risk suggesting introducing something simple and self-organizable.
> To be concrete: define "interest groups" by major areas of D ecosystem
> (Fronted, one for each backend, druntime as a whole, GC alone, Phobos in
> bits and pieces ...)  and let people join/leave/lead these.
>
> At the very least it would make it obvious who is into what at which
> point of time. Even more importantly - who you'd need to ask about what.
>
> The only question is where to track this stuff - maybe Wiki?

Could you please set up a sample wiki page so we get a better feel. Thanks.

> P.S. Trello was a failed experiment, but IMHO it failed largely due to
> being behind the closed doors.

Yah, the whole Trello experiment has been on my tongue during this discussion. It's been made public long before its demise.


Andrei

On Tuesday, 11 February 2014 at 17:12:37 UTC, Andrei Alexandrescu wrote:
>> Also I don't think volunteer effort can't be organized. It is a matter
>> of people identifying themselves as part of well-defined organization as
>> opposed to independent crowd of collaborators.
>
> I think we could organize ourselves better, too. It's all a matter of finding the right angle. But I think management is not what we need. We need better leadership. Big difference.

Probably. But one can't simply create leadership, this is something that comes naturally. Management is easier.

>> It is a common wisdom
>> that if no one feels directly responsible for an issue, no one will ever
>> pay attention to it.
>
> Yah, on the trite side even I'd opine :o). I said this several times now, and I'll say it again: I have asked SEVERAL TIMES people INDIVIDUALLY to do things that are HIGH IMPACT for the D language instead of something else that was more important to them, to no avail.

Of course, because you can't ask people to fulfill duties they have not volunteered to fulfill. This is exactly what I am speaking about - amount of people actually working on the language is actually very small despite high amount of contribution. Most people just do stuff they need or are interested in and can't be obliged to do anything else.

Volunteering to do stuff you don't really want is completely different thing :) And it needs to be encouraged by something more precious than tiny bounties. For example, being able to influence language-changing decisions is much more seductive reward.

> Of course, it would be learned helplessness to draw sweeping conclusions from the experience so far.
>
>> Do you need any specific proposals?
>
> Suggestions for doing things better are gladly considered.

As I have mentioned on some occasions, I was very impressed by both simplicity and efficiency of Arch Linux "Trusted User" organization after studying it "from inside". It is group of people that are not directly affiliated with Arch developers but have volunteered to take care/responsibility about parts of ecosystem. They also have power to make decisions regarding that ecosystem by formal voting procedure (with strict quorum and success % defined). Addition of new trusted users requires sponsorship from one of existing TU's and is approved by the very same voting procedure. Usually new TU's state clearly what parts of the ecosystem they want to be responsible for during initial application and this is often taken into consideration by voters.

I think D community can take some inspiration from such approach. It will allow to make decisions on more controversial topics and speed up process in general by removing bottleneck of your + Walter decision (assuming you still have veto votes in case stuff goes really bad). Also it gives clear overview of who is supposed to be responsible for what and feeling of making the difference for those who take part in it.

On 2/10/14, 4:25 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 10 February 2014 at 23:15:35 UTC, Andrei Alexandrescu wrote:
>> This is a typical problem. Reviewing contributions is hard and
>> thankless work. I know how we solved it at Facebook for our many
>> open-sourced projects: we created a team for it, with a manager,
>> tracking progress, the works. This is _exactly_ the kind of thing that
>> can't be done in a volunteer community.
>
> Maybe you can make some parts modular after you refactor into D. Then
> people can take ownership of modules and social recognition will
> encourage more commitment.

I think at this stage we need more people to start with. Someone pointed out recently we have 77 lifetime contributors to github, as opposed to e.g. Rust which has 292.

>> I think D must not define itself in relation to any other language.
>
> I respect that position.
>
> Of course, it does not help if outsiders have been told that D is a
> better C++. It kinda sticks. Because people really want that.

I don't think so, at all. Anyone working on D must drop the moniker "D is a better C++" like a bad habit, no two ways about that. Most of it does it sets C++ as the benchmark. People who already like C++ would be like "you wish" and people who hate C++ would be like "better crap is not what I need anyway".

> I am very hard trying to convince myself that D is more like compiled
> C#, which lowers my expectations, because that original vision of a
> "better C++" is very firmly stuck.

For someone who hasn't been around for a while, maybe. I fail to see C++ or C# mentioned anywhere on our home page.

We want to make D a great language all around, with system-level access and also convenience features.

> But my point was more that you need to communicate a vision that is such
> that the people you want to attract don't sit on the fence. I am quite
> certain that more skilled C++ programmers would volunteer if they saw a
> vision they believed in.

It's there in <h2> at the top of our homepage: "Modern convenience. Modeling power. Native efficiency."

By the way, this whole "plop a vision page" thing doesn't seem to be quite popular:

https://www.google.com/search?q=rust%20language#q=vision+site:rust-lang.org&safe=off

https://www.google.com/search?q=vision%20site%3Apython.org

https://www.google.com/search?q=vision%20site%3Aisocpp.org

https://www.google.com/search?q=scala#q=vision+site:scala-lang.org&safe=off

https://www.google.com/search?q=vision%20site%3Agolang.org


Andrei

On 2/11/14, 1:42 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Tuesday, 11 February 2014 at 02:15:37 UTC, Andrei Alexandrescu wrote:
>> On 2/10/14, 6:24 AM, "Ola Fosheim Grøstad"
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>> No, I don't think it is only a matter of resources. For instance, if I
>>> had the time
>>
>> Oh, the unbelievable irony.
>
> Not really. If you have too many outstanding issues it means you have
> added to many features. It means you failed to do feature freeze at an
> earlier stage.
>
> It could also mean that you don't give priority to mentoring. Sometimes
> it is better to let your best people do mentoring and help bringing
> "master level students" up to speed.
>
> People are not loyal to a project. People are loyal to other people. If
> a mentor invests time in you, you will feel a social debt. This is the
> principle of gifting.
>
> You can create a strategy for mentoring. One obvious one is to focus on
> making the code base suitable for academia. Then you can offer
> supervision of master students. Academics love to have good external
> supervisors taking some load off their backs. That means lowering the
> requirements for compilation speed in order to get in some high level
> optimization and other features that you cannot otherwise have.
>
> You can give priority to getting in support for more social bonding
> between developers, like give priority to an IDE that supports CSCW
> style collaboration (seeing the code view of others). With Skype that
> could make pair programming (from XP) possible.
>
> There are many options.

I confess I don't understand all of this (not sure whether the pointed-out irony has been acknowledged, not sure even whether it's subtle trolling), but upon reading it a couple of times I get the sense it's the exact management gobbledygook I'd like to protect this community from.


Andrei

On Tuesday, 11 February 2014 at 17:12:37 UTC, Andrei Alexandrescu wrote:
> I said this several times now, and I'll say it again: I have asked SEVERAL TIMES people INDIVIDUALLY to do things that are HIGH IMPACT for the D language instead of something else that was more important to them, to no avail.

Which things exactly?

On Tuesday, 11 February 2014 at 17:37:36 UTC, Andrei Alexandrescu wrote:
>
> Yah, the whole Trello experiment has been on my tongue during this discussion. It's been made public long before its demise.
>
>
> Andrei

I think it got off to a bad start because it was private and even after it was public it wasn't talked about much within the community (it was hard to even find because it wouldn't turn up in Trello's search). I use and enjoy Trello at work so personally I think I'd try to get everyone to give it another shot if it were up to me.

On Tuesday, 11 February 2014 at 17:50:54 UTC, Dicebot wrote:
>> Suggestions for doing things better are gladly considered.
>
> As I have mentioned on some occasions, I was very impressed by both simplicity and efficiency of Arch Linux "Trusted User" organization after studying it "from inside". It is group of people that are not directly affiliated with Arch developers but have volunteered to take care/responsibility about parts of ecosystem. They also have power to make decisions regarding that ecosystem by formal voting procedure (with strict quorum and success % defined). Addition of new trusted users requires sponsorship from one of existing TU's and is approved by the very same voting procedure. Usually new TU's state clearly what parts of the ecosystem they want to be responsible for during initial application and this is often taken into consideration by voters.
>
> I think D community can take some inspiration from such approach. It will allow to make decisions on more controversial topics and speed up process in general by removing bottleneck of your + Walter decision (assuming you still have veto votes in case stuff goes really bad). Also it gives clear overview of who is supposed to be responsible for what and feeling of making the difference for those who take part in it.

To give some specifics, one D example where we do have something resembling an organized process is Phobos review queue. Once I have noticed that there are lot of proposal rotting there (and that I don't like it) it was trivial to read the reiew process description, step up and proceed with all that stuff. Expectations were clear, process was (mostly) clear, same for responsibilities.

And main reward for that is that I can choose what gets reviewed next and poke people about their work :)

On 2/11/14, 10:08 AM, Andrej Mitrovic wrote:
> On Tuesday, 11 February 2014 at 17:12:37 UTC, Andrei Alexandrescu wrote:
>> I said this several times now, and I'll say it again: I have asked
>> SEVERAL TIMES people INDIVIDUALLY to do things that are HIGH IMPACT
>> for the D language instead of something else that was more important
>> to them, to no avail.
>
> Which things exactly?

One simple example: specific regressions and blockers in bugzilla.

Andrei