Fri 11 May 2018 7:45AM

PreVH as Open Source

KH Kirstin Heidler Public Seen by 324

I would like to know if the PreVH is developed as open source and where I can find the source code, so that I may contribute.
If it is not developed as open source I would like to know the reasons behind that and argue for making it open source.

If this was already covered somewhere, I apologize, I was not able to find anything concerining this issue.


Dieudonné Fri 11 May 2018 8:31AM

One of our intentions through choosing open source is precisely to allow contributors to contribute more easily to the work in progress. That's one of the reasons why opening this Loomio group. Initialy it was closed. In order to do that in a more efficient way, one of the first thing we choose to do was to decide to write a PreVH Weave Handbook. As you will see it's only the beginning. Thank you writing us this request : it helps us remember our work is not only to try to find the best technical solutions, but also to do it in way that allows others, to participate, even if they are not identified as part of the weave.
lately I wasn't in the bleeding edge research, but so far I can tell you we are on theses tracks :
* http://nvc-we.space/ for testing
* http://nvc-global.net/ for production

Software being explored at the moment :
* WordPress with BuddyPress plugin
* MediaWiki hosted on miraheze with pages accessible within WordPress through "RDP Wiki Embed" plugin. This wiki being particularly useful for cooperation around translations through the Translate extension.

Does this give you a beginning of an answer to your question ?


Bob W Fri 11 May 2018 5:34PM

@kirstinheidler A majority of the preVH "development" is likely to consist of selecting and integrating and configuring software components available elsewhere, rather than developing "code." To the extent that any new code is developed, I am in alignment with making it available to others -- to those in NVC-O for transparency, and more widely for code that has a chance of being of value to others.


Kirstin Heidler Sat 12 May 2018 11:29PM

Thank you for your answers. Coming from software development I believe I am used to different practices.
As far as I have understood you, the preVH is open source by your definition and any code that would be written would be released under an open source license.
I also understood that currently existing software is being configured and no "code" is written.

I came to this group and wondered how I could contribute, however I did not find much (plus I am probably looking for something different...). I agree that it is important to help people to contribute more easily. Maybe the linked Handbook could help in the future, currently it is pretty empty.

You said that software is being configured. What I would be looking for concerning this is configuration files and documentation. Documentation on how to configure the software, how to set everything up, how and where everything is hosted, how to set things up locally and test and on the design decisions made. There might also be documents to explain or explore certain parts. Documentation on where and how to contribute would also be good.

I like wikis, however wikis are not very transparent in my opinion concerning the decisions on what to accept as a change and what not. Furthermore, the wiki-structure concerning the roles is hierarchichal as I know it, although I may be mistaken.

Where do you keep your configuration files and documentation including revisions/versions?


Brent Barker Fri 18 May 2018 1:40AM

Hi Kirstin, glad to have you here! As someone coming from the "always prototyping" world of computational physics, I don't have the expertise I'd like with software development life cycles.

We have a development site, http://nvc-we.space/ , and a production site, http://nvc-global.net/ . We test out new features on the dev site, and then manually implement them on the production site. We do not implement any kind of version control yet.

I would love to have more design decisions logged, as well as user stories we want to be satisfying. With the team we have right now, it's my impression that our capacities are limited to the rapid prototyping going on, with the emphasis on getting something up and running now, and then working more carefully on the next iteration, knowing that the work we have now will inform that work.

I'm very curious about your reaction to all this, and how you might see yourself helping so far. I know we haven't provided an easy list of "bugs to fix", "features to implement", or anything like that yet. Maybe implementing a bug tracker might be helpful? What do you think hearing this?

And I invite you (and anyone else) to join us for our next meeting this Sunday, May 20, 21:00 - 22:30 UTC, https://roosevelt.zoom.us/j/122596111


Kirstin Heidler Tue 22 May 2018 10:03AM

Hi Brent, thank you for your invitation. I was camping and without internet. I regret I could not be there.

I understand that your focus is on getting something up, that works - at least prototypical. I also think this is very important. At the same time it is important to me, that it is discoverable (preferably wothout talking to people) why the software was built the way it is, i.e. what goal is feature xy trying to accomplish, and why was it built this way and not another. Sometimes this is obvious, sometimes it is not. This is important to me, because I would like others to be able and understand the project on a level that goes beyond being a user. I would like "outsiders" to be able to contribute. Furthermore I want the project to remain changeable. If the information on why and how things were built gets lost, then it gets harder to change the system in a way that takes into account, what has been done before.
This is a tradeoff. The documenatation and externalisation of knowledge takes time and it may seem that this takes time away from implementing features. However, consider the benefits mentioned above. Also writing documentation often brings new clarity to the one writing it, which may speed up implementation.

I am really curious to know how you see this. As far as I have understood you, you are also unsure how the documentation and externalisation of knowledge could be done. Is this true for you?
I have ideas, but of course my perspective is limited and I do not know, what you know. I would be glad to engage in a conversation.


Brent Barker Wed 23 May 2018 1:29AM

I agree with everything you've said. If you search in Loomio, there is some copy/paste of desired features in this Loomio somewhere. I'd love to find some time soon to start writing down my current understanding of our operating principles / criteria are, but I don't know when I'll find the time yet. Maybe you and I can chat and we can document what we discover about this?

I imagine doing that in a shared google doc while having a video chat, then moving that over to the miraheze wiki for future development. What do you think?

I'm also only speaking for my own understanding. Bob and Julie have been doing more of the back-end development than I have.


Kirstin Heidler Mon 28 May 2018 9:48AM

I would like to chat. We can try to find a time when this is possible. I believe it could be difficult because of different time zones and I have work and two children... not impossible, just difficult. :)


Brent Barker Tue 29 May 2018 9:19PM

Cool. Want to schedule wrangle over email instead of here? Then we can still invite others to the call too, if they can make it, if you'd like. me@brentwbarker.net


Bob Reckhow Sat 19 May 2018 8:11PM

I have some online software design and configuration experience, and the subjects that are always highest on my priority list are security, system integrity, and privacy. The Internet is a dangerous place, filled with "bad actors" everywhere, and so I believe it is very important to design security into the system from the very start, rather than treating it as something to be added in later, "when we have time".

(I apologize for the "enemy images" in the above sentence. I'm only trying to call attention to how things really are in the world, and in the Internet and the Wordpress technology space in particular.) There are a number of very effective and easy-to-implement security measures that are available in the open software space. Many of those measures address aspects of security, system integrity, and privacy at the same time - encryption being one good example.

I'd like to know if the current development plans have taken this perspective into account. Thanks.


Bob W Sat 26 May 2018 1:40AM

@bobreckhow As one bit of incremental progress, the entire site is now HTTPS-enabled. Thanks, Julie!

I haven't yet given time to researching security best-practices for WordPress sites (beyond looking at the options for protecting email addresses and not being satisfied with any of them, beyond simply never including addresses on pages that are public -- I'd still like to better protect addresses even if only available to logged in users). If someone would like to call specific security measures applicable to Wordpress to our attention, I imagine that could be helpful.


Dieudonné Tue 22 May 2018 2:31PM

Thank you Kristin for putting in words what I is hard to explain,
since english is not my first language and you seem to have
understood what is more like an intuition for me.

Le 22/05/2018 à 12:03, Kirstin Heidler
(Loomio) a écrit :


Julie Sat 26 May 2018 12:54AM

Hi Kristen, sorry I haven't had time to write on this thread before now!! I'm not sure if anyone's clarified for you that we're developing a Wordpress site. Wordpress is itself open source, and most of the plugins we're using are also open source. Sometimes we're unable to find free plugins that will do what we want, and then we buy things - the code is still "open-source" to a degree (ie. you can read and modify it directly), but paid for. Are you familiar with Wordpress?


Kirstin Heidler Mon 28 May 2018 8:53AM

Hi Julie,
I am familiar with wordpress in the sense that I know what it is and have used it before. However I would not call myself an expert since I have never tried to develop anything for it nor have I tried to customize it to an extreme. I know however, it is written in php.

I do not know how you are developing your site or how you are hosting it. I would really like to get to know more about this.
I believe that you are using config files and so on and I would like to suggest, that these could be open source in every sense of the word. Concerning plug-ins you paid for, these could be added to a repository as well, but would probably need their respective license, which may not be an open/free license (like e.g. GPL, MIT...).


Dieudonné Mon 28 May 2018 9:23AM


Kirstin Heidler Mon 28 May 2018 11:23AM

Yes, I can see them and took a look.


Bob W Sat 26 May 2018 1:31AM

@kirstinheidler Thanks for your suggestions/requests. I plan to track any actual code in git. We don’t have a public repository as yet. Most configuration is done through the WordPress console and stored in the database. I’m not clear on how best to version control that. Suggestions welcome.

I didn’t entirely follow your thoughts about wikis. Perhaps more later; plane is about to depart.

Your questions may not correspond to the actual maturity/newness of this initiative. We are still trying to get systems in place, while generating a usable quick website ASAP. Standards for the preVH and VH may be different; that latter will ideally be more rigorous. And, it would be great for the preVH to have as solid systems as we can pull off while addressing the immediacy of the needs involved


Kirstin Heidler Mon 28 May 2018 9:41AM

Hi Bob, thank you for clarifying some of the process to me. Especially how you configure WordPress gave me some insight.
My thoughts on that:
If you can type it into a console then a script can do it, too.
For products in production this is done via so called "migrations". At least that is the term I have learned and used. Migrations are ordered by time stamp and always executed in this order. Migrations always include code on how to alter the database and they may also include code, to roll the change back (if possible). Migrations have the benefit that you could easily create the same kind of database (not necessairly filled with the same data) again and again as part of a repeatable process. (For example this could be useful for setting up a local environment , for testing or for creating a copy/new instance/repairing the system after it broke badly).
I hope I am not explaining something to you, you already know. I just want to be helpful. Please let me know your thoughts on migrations.

I believe some forms of documentation can be done right from the start of a project and I believe this is very helpful. It is soooo incredibly hard to create meaningful documentation after the software is "feature complete". I believe this is the case, because people who did not write the code/implement the feature will write documentation for something they did not create themselves (or even if they have created it, it was some time ago and memory fades). There may be no more documentation than the bare source code or the state of the database, which does not reveal much about intentions and the bigger picture.
Now it may not be as bad, if you are just plugging things together, since at least the individual parts might be documented (by someone else). But I still believe that going forward from anything is easier if the current (and past) can be understood.

The documentation I believe is vital is: what did we do?, why did we do it?, why did we do it this way? (design decisions, encountered obstacles). How to set everything up?
What can be omitted in my opinion: user guides, tutorials, (in-depth API documentation)...

I am curious about your thoughts.


Bob W Sat 26 May 2018 6:58PM

@kirstinheidler As a step towards software transparency, I have just added a page to the website, Website Source Code, that exposes to logged in Members all website customizations that are encoded in files (as opposed to being stored in the database).


Brent Barker Sat 26 May 2018 7:10PM

@bobw This link leads to an empty page for me, and I also cannot discover it from the home page.


Bob W Sat 26 May 2018 7:15PM

@brentbarker That is the expected behavior if you are not logged in to the preVH site. Log in and then try it.

The menu item for this page currently lives under the "Contact" menu item. This is awkward placement; I imagine eventually the menu will be organized in a way that offers a more natural home.


Brent Barker Sat 26 May 2018 7:40PM

Got it. It'd be good to have a landing page that says something like, "you need to log in to view this page". Otherwise it looks broken to me. Should I add that to the requested features list, or make a bug/issue section?


Bob W Sat 26 May 2018 8:03PM

For most members-only pages I do that. For this page, I specifically chose not to do that. I feel nervous about advertizing to hackers that they can come read our source code as an aid to hacking us. So, I'm happy for the page to be confusing to non-logged-in users --- who should never have any reason to see this page in the first place -- rather than telling hackers clearly, please create a login and come figure out how to hack us.

Does that make any sense to you?


Brent Barker Sat 26 May 2018 8:17PM

Yep, perfectly.


Bob W Sat 26 May 2018 9:25PM

I will add that we now also have the file-based information source-code controlled, in a private git repository on our server.

(Eventually, I could imagine offering access to different file versions, or visibility into the repository, or exporting the data to a public git repository. However, given current project priorities, I'd like to defer that until later. I see policy as well as technical issues potentially being involved.)